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Abstract 


A  Non-Combatant  Evacuation  Operation  (NEO)  is  designed  to  deploy  forces  in  a  short  or 
no-notice  situation  as  a  result  of  a  deteriorating  situation  in  an  foreign  nation  where  the 
safety  of  Canadians  abroad  is  adversely  affected.  In  the  event  of  a  rapidly  deteriorating  civil 
situation  that  may  overwhelming  local  authorities,  the  Department  of  Foreign  Affairs,  Trade 
and  Development  (DFATD)  may  seek  assistance  from  the  Canadian  Armed  Forces  (CAF) 
in  order  to  conduct  an  evacuation  of  the  Canadians  from  the  affected  nation. 

In  support  of  Canadian  Joint  Operational  Command  (CJOC)  (and  by  extension  DFATD 
and  1st  Canadian  Division  Headquarters  planners),  the  CJOC  Operational  Research  and 
Analysis  (OR&A)  Team  initiated  the  development  of  the  Simulation  Tool  for  Optimizing  Non- 
Combatant  Evacuation  (STONE)  analysis  toolset  to  support  NEO  planning.  This  Scientific 
Report  documents  the  STONE  optimization  component,  STONE(Opt).  STONE(Opt)  can 
help  to  determine  the  best  allocation  and  utilization  of  transportation  resources  and  estimate 
evacuation  time. 

Significance  for  defence  and  security 


The  Government  of  Canada  bears  a  fundamental  responsibility  for  the  safety  and  well-being 
of  all  Canadians.  The  DFATD  assumes  this  responsibility  for  Canadians  living  abroad. 
Following  the  evacuation  of  approximately  13,000  Canadian  or  Eligible  Persons  (CEPs)  from 
Lebanon  in  2006,  a  Standing  Senate  Committee  on  Foreign  Affairs  and  International  Trade 
recommended  that  more  frequent  assessments  of  NEO  plans  be  conducted,  particularly  for 
those  areas  with  large  Canadian  resident  populations  and  areas  where  the  potential  for 
destabilization  is  high,  to  ensure  thorough  contingency  planning  and  logistical  preparation 
for  large-scale  emergencies,  and  assessments  of  resources  required  for  that  mission. 

This  Scientific  Report  presents  a  mathematical  optimization  model  that  has  the  potential 
to  enable  better  understanding  of  the  feasibility  and  efficiency  of  logistic  operations  of  a 
NEO,  helping  senior  decision  makers  to  better  plan  and  execute  a  NEO.  In  particular, 
STONE(Opt)  can  be  used  to: 

•  determine  the  number  of  resources  required  versus  desired  evacuation  time; 

•  estimate  the  number  of  evacuees  at  particular  locations  and  time; 

•  assess  the  feasibility  of  evacuation  timeline  given  sites’  capacities; 

•  estimate  resource  utilization  rates; 

•  determine  the  optimal  allocation  of  transportation  resources  and  their  schedules;  and 

•  estimate  the  evacuation  rate  of  evacuees  to  safe  havens. 
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Resume 


Une  operation  d’evacuation  de  non-combattants  (OEN)  consiste  a  deployer  des  forces  sans  ou 
avec  tres  peu  de  preavis  dans  une  region  ou  la  situation  se  deteriore  et  ou  il  existe  une  menace 
pour  la  securite  ou  la  sante  de  Canadiens  a  l’etranger.  Dans  le  cas  ou  la  situation  se  degrade 
trop  rapidement  ne  permettant  pas  aux  autorites  locales  de  repondre  adequatement  aux 
besoins  requis  pour  affronter  la  situation,  le  Ministere  des  affaires  etrangeres,  du  commerce 
et  du  developpement  (MAECD)  peut  demander  l’aide  des  Forces  armees  canadiennes  (FAC) 
pour  rnener  une  evacuation. 

En  soutien  aux  planificateurs  du  Commandement  des  operations  interarmees  du  Canada 
(COIC)  et  par  le  fait  meme  a  ceux  du  MAECD  et  du  Quartier  general  de  la  Ire  Division 
du  Canada,  l’equipe  d’analyse  et  de  recherche  operationnelle  du  COIC  a  developpe  des 
outils  d’analyse  pour  aider  a  la  preparation  des  OEN.  Le  present  rapport  decrit  un  module 
d ’optimisation  faisant  parti  d’un  outil  nomme  STONE  ( Simulation  Tool  for  Optimizing 
Non-Combatant  Evacuation).  Ce  module  permet  de  determiner  la  meilleure  maniere  d’allouer 
et  d’utiliser  les  ressources  de  transports  lors  d’une  OEN  et  d’estimer  le  temps  necessaire 
pour  completer  l’evacuation. 


Importance  pour  la  defense  et  la  securite 


Le  gouvernement  du  Canada  est  responsable  de  la  securite  et  du  bien-etre  de  tous  les 
Canadiens.  Le  MAECD  assume  cette  responsabilite  pour  les  Canadiens  qui  se  trouvent  a 
l’etranger.  A  la  suite  de  l’evacuation  de  quelque  13  000  Canadiens  du  Liban  en  2006,  un  comite 
senatorial  permanent  des  Affaires  etrangeres  et  du  commerce  international  a  recommande  que 
des  evaluations  dans  ses  missions  a  l’etranger  soient  faites  plus  frequemment,  particulierement 
celles  qui  sont  situees  dans  une  region  a  forte  proportion  de  residents  Canadiens  et  celles  ou 
le  risque  de  destabilisation  est  eleve.  II  pourrait  ainsi  actualiser  1’evaluation  des  risques  de  la 
region  et  des  risques  pour  les  Canadiens,  planiher  minutieusement  les  mesures  d’urgence 
et  la  logistique  d’une  situation  d’urgence  a  grande  echelle,  ainsi  qu’evaluer  les  ressources 
necessaires  a  une  telle  mission. 

Le  travail  decrit  dans  ce  rapport  permet  en  partie  d’adresser  cette  recommandation.  Plus 
specihquement,  ce  rapport  presente  un  modele  d’optimisation  mathematique  qui  permettra 
une  meilleure  comprehension  de  la  faisabilite  et  de  l’efhcacite  des  operations  logistiques  lors 
d’une  evacuation  de  non-combattants,  aidant  ainsi  les  hauts  fonctionnaires  a  mieux  planiher 
et  mettre  en  oeuvre  une  OEN.  Entre  autre,  le  modele  peut  repondre  a  des  questions  telles 
que  : 


•  determiner  le  nombre  de  ressources  necessaires  pour  une  evacuation  en  un  temps 
desire ; 


estimer  le  nombre  d’evacues  a  des  endroits  specihques  en  fonction  du  temps ; 

evaluer  la  faisabilite  d’un  plan  d’evacuation  en  considerant  le  nombre  de  ressources 
disponibles  ainsi  que  la  capacite  maximale  des  sites ; 
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•  estimer  les  taux  d’utilisation  des  ressources ; 

•  determiner  l’affectation  optimale  des  ressources  et  de  leurs  horaires 

•  estimer  le  taux  d’arrivee  des  evacues  a  l’endroit  de  securite. 
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1  Introduction 


1.1  Background 

A  Non-Combatant  Evacuation  Operation  (NEO)  is  designed  to  deploy  forces  in  a  short 
or  no-notice  situation  as  a  result  of  a  deteriorating  situation  in  an  Affected  Nation  (AN) 
that  is  threatening  the  safety  of  Canadians.  NEO  is  defined  by  North  Atlantic  Treaty 
Organization  (NATO)  as  an  “operation  conducted  to  relocate  designated  non-combatants 
threatened  in  a  foreign  country  to  a  place  of  safety”  [1] . 

Large  scale  NEO  are  extremely  complex;  often  being  conducted  in  a  hostile  environment, 
dealing  with  multiple  uncertainties,  and  requiring  whole  of  government  expertise  and 
coordination  across  multiple  issues.  Cooperation  between  friendly  countries  is  very  important 
but  also  adds  to  the  complexity  as  every  nation  is  evacuating  their  citizens  from  the  conflict 
region  while  competing  for  the  same  support  and  resources  (e.g.  transporters,  assembly 
points/evacuation  centres).  For  example,  the  2006  NEO  in  Lebanon  exhibited  the  full 
spectrum  of  complexities  where  approximately  50  countries  were  evacuating  their  citizens 
from  threatening  circumstances  to  a  safe  location  [2],  The  Lebanon  crisis  is  the  largest-scale 
NEO  in  Canadian  history  where  an  estimated  13,000  Canadian  or  Eligible  Persons  (CEPs)1 
were  evacuated  during  the  operation  [4] . 

The  Government  of  Canada  bears  a  fundamental  responsibility  for  the  safety  and  well  being 
of  all  Canadians.  The  Department  of  Foreign  Affairs,  Trade  and  Development  (DFATD) 
assumes  this  responsibility  for  Canadians  living  abroad.  The  largest  Canadian  populations 
abroad  by  country,  rounded  to  the  nearest  thousand,  are  listed  in  Table  1.  The  data  was 
compiled  from  various  sources  [5] . 


Table  1:  The  largest  Canadian  populations  abroad  by  country. 


Country  or  Territory 

Canadian  citizens 

Country  or  Territory 

Canadian  citizens 

United  States 

1,063,000 

Egypt 

10,000 

Hong  Kong  SAR 

300,000 

New  Zealand 

7,800 

United  Kingdom 

73,000 

Philippines 

7,500 

Lebanon 

45,000 

Haiti 

6,000 

Australia 

27,000 

Mexico 

5,800 

China  (mainland) 

20,000 

Switzerland 

5,000 

South  Korea 

14,000 

Singapore 

5,000 

Germany 

13,000 

Thailand 

5,000 

United  Arab  Emirates 

12,000 

Trinidad  and  Tobago 

5,000 

France 

12,000 

Belgium 

4,000 

Japan 

11,000 

1  CEPs  are  “Canadian  citizens  (civilian  but  also  military  personnel  classified  as  non-combatant  and  non- 
essential),  categories  of  persons  holding  legal  status  in  Canada  (ranging  from  landed  immigrants  to  various 
visa  holders)  as  specified  by  the  Canadian  Government,  and  designated  third-country  nationals  and  [host 
nation]  persons  as  specified  by  the  Canadian  Government,  deemed  to  be  eligible  applicants  for  evacuation”  [3]. 
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The  DFATD  leads  and  coordinates  any  NEO  on  behalf  of  the  Government  of  Canada. 
In  the  event  of  rapidly  deteriorating  civil  environment  where  there  is  high  risk  that  the 
DFATD’s  mission  (embassy,  consulate,  etc.)  for  the  affected  nation  may  be  overwhelmed — i.e. 
when  all  other  options  for  helping  Canadians  and  eligible  persons  leave  an  affected  zone 
have  been  exhausted — the  DFATD  may  seek  assistance  from  the  Department  of  National 
Defence  (DND)  and  the  Canadian  Armed  Forces  (CAF)  to  conduct  an  evacuation.  Other 
departments  and  organizations  including,  but  not  limited  to,  the  Canada  Border  Services 
Agency  (CBSA),  the  Canadian  Security  Intelligence  Service  (CSIS),  the  Citizenship  and 
Immigration  Canada  (CIC)  and  the  Royal  Canadian  Mounted  Police  (RCMP)  also  support 
the  DFATD  as  required. 

Given  its  complex  nature,  strategic  and  comprehensive  planning  and  preparation  are  key 
to  a  successful  NEO.  This  was  stressed  in  the  final  report  produced  by  a  Standing  Senate 
Committee  on  Foreign  Affairs  and  International  Trade  following  the  Lebanon  evacuation  in 
2006  [6].  Recommendations  2  and  4  in  the  final  report  were  as  follows: 

Recommendation  2:  The  Department  of  Foreign  Affairs  and  International  Trade 
should  conduct  more  frequent  assessments  of  its  missions  abroad,  particularly  those 
situated  in  areas  with  large  Canadian  resident  populations  and  areas  where  the 
potential  for  destabilization  is  high,  to  ensure  updated  risk  assessments  of  the  region 
and  the  risks  to  Canadians,  thorough  contingency  planning  and  logistical  preparation 
for  large-scale  emergencies,  and  assessments  of  resources  required  for  that  mission. 

Recommendation  4:  In  undertaking  large-scale  evacuations  like  the  case  of 
Lebanon  in  2006,  the  Department  of  National  Defence  and  Canadian  Forces  should 
coordinate  and  lead  the  government’s  evacuation  effort,  particularly  so  that  DND 
personnel  can  oversee  the  security  and  logistics  of  the  operation  and  the  movement 
of  large  numbers  of  Canadians. 

The  DND  Joint  Doctrine  Manual  on  NEO  [3]  formally  defines  NEO  as  a  “military  operation 
conducted  to  assist  the  DFATD  in  evacuating  Canadians  and  selected  non-Canadians  from 
threatening  circumstances  in  a  foreign  affected  nation  and  moving  them  to  a  safe  haven”. 
When  DND  assistance  is  solicited,  the  CAF  are  typically  requested  to  assist  DFATD  in  the 
overall  evacuation  process,  including  planning  and  execution,  and  to  provide  appropriate 
security.  The  Canadian  Joint  Operational  Command  (CJOC)  develops  Contingency  Plan 
(CONPLAN)  ANGLE  [7]  and  the  1st  Canadian  Division  Headquarters  (1st  Cdn  Div  HQ), 
a  suboordinate  command  to  CJOC,  has  the  task  of  preparing  a  country-specific  Operational 
Plan  (OPLAN). 

In  support  of  CJOC  and  1st  Cdn  Div  HQ  planners,  the  CJOC  Operational  Research  and 
Analysis  (OR&A)  Team  initiated  the  development  of  an  analysis  toolset  to  support  NEO 
planning  within  the  CAF  and  by  extension  DFATD  other  Canadian  organizations.  The 
toolset  is  named  Simulation  Tool  for  Optimizing  Non-Combatant  Evacuation  (STONE). 
This  work  is  part  of  an  overarching  Assistant  Deputy  Minister  Science  and  Technology 
(ADM(S&T))  project  that  delivers  operational  and  strategic  research  and  analysis  support 
to  CJOC. 


2 


DRDC-RDDC-2015-R074 


1 .2  Previous  work 


An  examination  of  the  literature  within  DND  showed  that  NEO  in  Canada  has  been  studied 
in  the  recent  past  mainly  through  reviews  of  policy,  departmental  doctrine  and  case  studies  - 
in  particular  with  papers  produced  at  the  Canadian  Armed  Forces  Staff  College  [8,  9].  It 
appears  however  that  from  an  OR&A  and  Modelling  and  Simulation  (M&S)  perspective, 
this  subject  has  not  been  studied  within  a  Canadian  context. 

Scientific  research  on  NEO  has  been  undertaken  in  the  United  States.  For  instance,  the  Naval 
Postgraduate  School  developed  an  optimization  model  using  integer  linear  programming 
to  plan  non-combatant  evacuation  [10,  11],  an  effort  sponsored  by  the  Center  for  Army 
Analysis  (C AA) .  C AA  claimed  to  provide  analysis  using  the  optimization  model  for  planners 
in  the  Africa,  Europe  and  Pacific  regions  in  support  of  operational  plan  development, 
exercises  and  crisis  planning  [11].  The  Naval  Postgraduate  School  models,  implementations, 
and  documentation  (beyond  presentation  slides)  were  not  made  available  to  the  authors. 

The  Air  Force  Institute  of  Technology  (AFIT)  [12-14]  and  the  CAA  [11,  15]  also  proposed 
NEO  models  and  analysis  based  on  Discrete-Event  Simulation  (DES).  DES  has  also  been 
used  by  the  CAA  to  evaluate  various  courses  of  action  and  support  decision  making  in  real 
crisis. 

Within  the  Ministere  de  la  Defense  (France),  the  Centre  de  doctrine  d’emploi  des  forces 
division  simulation  et  recherche  operationelle  (DSRO)  planned  the  development  of  successive 
modelling  and  analysis  to  optimize  the  deployment  and  operation  of  NEO  in  support  of 
the  commandment  de  la  force  logistique  terrestre.  Initial  modelling  efforts  were  to  focus 
on  the  flow  of  CEPs  through  evacuation  centres  [16].  It  was  anticipated  that  the  tool 
developed  would  benefit  planning  requirements  for  lodging,  food,  and  transportation  out  of 
the  evacuation  centres.  The  authors  could  not  identify  any  follow-up  to  the  proposed  DSRO 
modelling  plans. 

In  an  effort  to  gain  better  insight  into  the  modelling  and  analysis  efforts  of  representative 
countries  (including  details  of  United  States  CAA  and  France’s  DSRO  efforts  to  date), 
and  recognizing  the  need  for  international  cooperation,  a  NATO  Science  and  Technology 
Organization  (STO)  Systems  Analysis  and  Studies  (SAS)  technical  activity  [17]  was  initiated 
in  2015  to  enable  NATO,  NATO  Partnership  for  Peace,  and  NATO  Global  Partners  countries 
to  collaborate  in  OR&A  support  to  NEO. 

1 .3  Objective 

The  objective  of  this  research  is  to  enhance  the  NEO  planning  capabilities  of  DFATD,  CJOC, 
and  1st  Cdn  Div  HQ  planners.  The  report  presents  an  optimization  model  built  into  a 
graphical  interface  that  provides  a  better  understanding  of  the  feasibility  and  logistical 
complexities  of  NEO,  with  the  ultimate  goal  of  enabling  senior  decision  makers  to  better 
plan  and  prepare  NEO  execution.  The  NEO  modelling  toolset,  STONE,  that  is  currently 
being  developed  by  the  CJOC  OR&A  Team  comprises  of  three  main  components: 
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1.  visualization  -  to  provide  situational  awareness  by  quickly  and  automatically  creating 
maps  that  show  geographic  site  locations  and  the  connectivity  between  them  in  the 
form  of  “map  layers”; 

2.  optimization  -  a  mathematical  model  to  help  determine  best  allocation  and  utilization 
of  resources  and  estimate  evacuation  timeline;  and 

3.  simulation  -  a  discrete  event  simulation  to  model  the  operation  which  enables  an 
analyst  to  perform  “what-if”  type  analysis,  characterize  uncertainty,  evaluate  various 
courses  of  action,  and  estimate  queue  size  and  time  spent  by  evacuees  in  the  system 
and  at  specific  locations. 

The  herein  Scientific  Report  documents  the  elements  of  the  mathematical  optimization  model 
(item  2).  The  optimization  component  of  STONE  is  henceforth  referred  to  as  STONE(Opt). 
STONE(Opt)  can  be  used  to: 

•  determine  the  number  of  resources  required  versus  desired  evacuation  time; 

•  estimate  the  number  of  evacuees  at  particular  locations  and  time; 

•  assess  the  feasibility  of  evacuation  timeline  given  sites’  capacities; 

•  estimate  resource  utilization  rates; 

•  determine  the  optimal  allocation  of  transportation  resources  and  their  schedules;  and 

•  estimate  the  evacuation  rate  of  evacuees  to  safe  havens. 

It  is  anticipated  that  STONE(Opt)  has  analogous  concepts  to  the  model  developed  by  the 
United  States  CAA  as  both  model  the  movement  of  CEPs  through  NEO  sites  and  the 
allocation  of  transportation  resources  to  accomplish  the  movement. 

1 .4  Outline  of  the  report 

The  report  is  structured  so  as  to  provide  NEO  planners  a  high  level  of  understanding  of 
the  potential  capabilities  of  STONE.  Details  of  the  model  implementation  and  development 
information,  valuable  to  users  and  analysts,  are  deferred  to  appendices. 

This  Scientific  report  contains  four  more  sections.  Section  2  provides  definitions,  assumptions 
and  describes  the  aspects  of  a  NEO  operation  that  are  considered  in  STONE(Opt).  The 
NEO  optimization  problem  was  mathematically  modelled  and  is  presented  at  a  high  level  in 
Section  3.  Section  4  presents,  using  a  notional  scenario,  examples  of  questions  that  can  be 
answered  and  types  of  analysis  that  can  be  conducted  with  STONE(Opt).  Conclusions  and 
proposed  areas  for  future  work  are  summarized  in  Section  5.  Annex  A  presents  the  Graphical 
User  Interface  (GUI)  developed  for  STONE(Opt).  It  facilitates  input  generation,  model 
generation,  optimization,  and  output  processing.  Annex  B  documents  the  mathematical 
formulation  of  STONE(Opt)  and  Annex  C  documents  the  software  implementation  of  the 
mathematical  formulation. 
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2  Evacuation  process 


This  section  provides  a  general  overview  of  the  NEO  process  and  definitions  considered  in 
STONE(Opt)  that  will  be  presented  later  in  Section  3.  The  process  is  mainly  based  on  the 
information  found  in  the  Canadian  Joint  Doctrine  Manual  on  NEO  [3].  Doctrinal  material 
from  other  nations  such  as  the  United  States  [18],  the  United  Kingdom  [19]  and  France  [20] 
were  also  reviewed.  Each  nation  uses  different  plans  and  terminology;  however,  the  general 
structure  and  elements  of  a  NEO  are  very  similar. 

Other  key  Canadian  documents  detailing  NEO  planning  are  also  briefly  discussed  in  this 
section.  References  to  the  2006  Lebanon  evacuation  are  used  to  illustrate  the  evacuation 
process  and  its  various  elements. 

2.1  Typical  evacuation  chain 

The  NEO  process  considered  in  this  Scientific  Report  is  illustrated  in  Figure  1.  The  geography 
of  the  affected  nation,  the  threat  environment  (permissive  versus  hostile)  and  the  political 
context  at  the  time  of  the  crisis  make  every  NEO  unique.  Although  no  two  NEOs  are  the 
same,  the  generic  elements  of  the  evacuation  chain  are  identical.  They  include:  Assembly 
Points  (APs),  Evacuation  Centres  (ECs),  Safe  Havens  (SHs)  and  Repatriation  Sites  (RSs). 
The  four  elements  of  the  process  are  outlined  in  the  paragraphs  below. 


Figure  1:  Non-combatant  evacuation  process. 

Assembly  points  (APs):  The  APs,  which  are  often  schools,  churches  or  hotels,  are 
normally  first  in  the  evacuation  chain.  Typically,  the  CEPs  make  their  own  way  to  an 
AP  -the  one  communicated  to  them  by  the  mission.  The  APs  are  intended  to  serve  as 
meeting  points  while  the  CEPs  await  transport  to  an  EC.  Typically  the  transfer  of  CEPs 
from  an  AP  to  an  EC  is  done  through  CEPs’  own  transport  and/or  transport  set  up  by  the 
embassy.  Of  note,  depending  on  their  personal  circumstances,  CEPs  may  not  report  to  an 
AP  and  instead  proceed  directly  to  an  EC  from  their  place  of  residence. 
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Evacuation  centres  (ECs):  According  to  DND  doctrine  [3],  an  EC  is  “the  main  processing 
facility,  where  basic  screenings  are  conducted  (or  completed)  and  detailed  processing  takes 
place.  An  EC  must  also  act  as  an  AP  for  evacuees  proceeding  directly  to  it  from  their  place 
of  residence.”  ECs  are  secure  sites  and  are  likely  to  be  located  at,  or  in  the  proximity  of, 
an  airport,  a  sea  port  or  a  land  border.  The  screening  and  processing  that  occur  at  an 
EC  is  intended  to  admit  to  or  eliminate  from  the  evacuation  chain  each  person  wanting  to 
leave  the  affected  nation.  Identities  are  confirmed,  and  security  and  medical  checks2  are 
performed.  If  eligible,  the  CEPs  are  then  prioritized  for  transportation  outside  the  affected 
nation.  Once  at  an  EC,  the  transport  of  CEPs  is  arranged  by  the  Government  of  Canada, 
typically  using  sealift  or  airlift  assets. 

Safe  havens  (SHs):  A  SH  is  defined  as  “an  area  beyond  the  effects  of  the  disturbance  to 
which  evacuees  are  removed  and  in  which  they  are  administered  pending  final  disposition.  It 
may  be  elsewhere  in  the  host  nation,  in  another  country,  on  one  of  Her  Majesty’s  Canadian 
Ships,  or  in  Canada  itself”  [3].  At  the  SHs,  CEPs  are  safe  from  threat  and  await  onward 
movement  to  the  RS  or  back  to  the  affected  nation  once  the  disturbances  have  ceased. 

Repatriation  site  (RS):  For  the  purpose  of  this  work,  RS  refers  to  a  place  of  safety  where 
the  CEPs  exit  the  evacuation  chain  and  are  no  longer  dependent  on  diplomatic  or  military 
assistance.  In  most  NEO  instances,  the  RS  is  Canada  itself. 

STONE(Opt)  focuses  on  the  movement  of  CEPs  from  APs  to  ECs  to  SHs  and  the  related 
transporation  resources  required  for  that  movement.  STONE(Opt)  does  not  model  the 
processing  of  CEPs  at  a  particular  site,  apart  from  factoring  a  fixed  processing  time. 

2.2  Key  NEO  planning  documents 

The  Joint  Doctrine  Manual  on  NEO  [3]  details  CAF  procedures  and  processes  to  support 
the  evacuation  of  Canadians  abroad.  Two  other  key  sets  of  publications  on  Canadian  NEO 
planning  are  the  following: 

CAF  Operational  Level  Plans:  CONPLAN  ANGLE  [7]  is  maintained  by  CJOC  and 
serves  as  a  functional  plan  for  NEO.  It  uses  the  Joint  Doctrine  Manual  on  NEO  as  a  basis 
and  expands  to  form  a  bridge  between  the  strategic  level  and  the  tactical  level  plan  [8]. 
The  CONPLAN  focusses  mainly  on  command  and  control,  force  generation  and  how  the 
forces  would  be  deployed  overseas  to  assist  DFATD  during  the  crisis.  CJOC  also  maintains 
CONPLAN  ANGLE  Eastern  Mediterranean  (EM)  which  is  more  focussed,  serving  as  an 
operational  /  geographic  CONPLAN  [21]. 

Mission  Emergency  Plan  (MEP):  The  DFATD  is  responsible  for  developing  and  main¬ 
taining  contingency  plans,  referred  to  as  MEPs3,  that  cover  evacuation  of  non-combatants 

2  Medical  checks  are  not  a  standard  part  of  the  process  but  it  can  be  conducted  when  a  CEP  is  visibiliy  sick 
or  if  there  is  a  known  outbreak  of  a  worrisome  illness  in  the  area. 

3  The  MEPs  were  formally  known  as  the  Consular  Emergency  Contingency  Plan  (CECP). 
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in  all  nations.  These  plans  are  “designed  to  provide  guidance  to  missions  to  assist  them  in 
their  response  regarding  the  safety  of  Canadians  before,  during  the  lead  up  to,  and  during 
crises”  [3].  The  MEP  is  the  foundation  document  in  the  event  of  an  emergency  necessitating 
an  evacuation.  It  provides  information  and  instructions,  including,  but  not  limited  to: 

•  total  number  of  CEPs  and  break  down  by  area; 

•  evacuation  chain  data,  with  the  locations  (primary  and  alternate)  of  evacuation 
facilities  (APs  and  ECs),  routes  (primary  and  alternate),  and  points  of  contact  for 
facilities,  contracts,  etc.; 

•  evacuation  supporting  data,  particularly  the  locations  and  technical  data  for  terminals 
(e.g.  airports,  sea  ports,  beach  sites),  existing  transportation  infrastructure  and 
commercial  links  (air,  land  and  sea)  in  the  affected  nation; 

•  CEPs’  notification  system4 5;  and 

•  warden  system. 

The  CAF,  who  are  expertly  trained  in  logistics,  security  and  crisis  planning,  assist  DFATD 
in  the  development  of  some  MEPs — those  pertaining  to  higher  risk  areas.  The  method 
through  which  they  assist  DFATD  is  called  a  Contingency  Planning  Assistance  Team  (CPAT). 
During  a  CPAT,  a  joint  DND  and  DFATD  team  visits  a  specific  region  (usually  visiting 
three  missions  in  the  region)  in  order  to  enhance  existing  evacuation  plans.  The  team  then 
reviews  the  relevance  of  the  plans  to  determine  where  CAF  support  may  be  required,  and  to 
increase  DND  situational  awareness  of  conditions  and  challenges  in  the  area.  At  the  onset  of 
a  crisis,  the  CAF  may  also  send  a  strategic  reconnaissance  team  (mainly  1st  Cdn  Div  HQ 
personnel)  to  assist  with  the  preparation  of  more  detailed  plan. 

Most  of  the  required  inputs  to  STONE(Opt)  are  presented  in  the  MEP.  The  results  of 
STONE(Opt)  can  be  used  to  influence  MEP  development  (e.g.  setting  capacity  requirements 
for  evacuation  facilities),  or  to  help  validate  the  contingency  plans. 

2.3  NEO  elements  in  the  2006  evacuation  in  Lebanon 

Table  2  shows  the  NEO  elements  of  the  2006  evacuation  in  Lebanon.  At  the  time,  there 
was  an  estimated  50,000  Canadians  living  in  or  visiting  the  country.  As  discussed  briefly 
above,  during  an  evacuation,  not  all  elements  are  necessarily  used  or  activated.  For  the 
2006  Lebanon  operation,  the  plan  had  CEPs  transit  directly  from  home  locations  to  the  EC, 
eliminating  the  use  of  APs. 

An  EC  was  established  at  the  Port  of  Beirut  where  the  CEPs  embarked  on  ships  which 
sailed  to  one  of  the  two  safe  havens  -  Lanarka,  Cyprus  and  Adana,  Turkey.  According  to 

4  These  plans  cover  all  nations,  but  there  is  not  necessarily  a  plan  dedicated  for  each  individual  nation.  The 
MEPs  are  done  by  the  missions — each  mission  is  accredited  to  specific  countries. 

5  The  notification  system  is  called  the  Registration  of  Canadians  Abroad  (ROCA)  system.  Through  this 
system,  Canadians  whom  are  registered  (voluntarily)  in  the  system,  are  notified  when  the  mission  recommends 
an  evacuation. 
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Table  2:  Sites  used  in  the  2006  NEO  in  Lebanon. 


NEO  elements 

Locations 

Assembly  points 

- 

Evacuation  centre 

Port  of  Beirut,  Lebanon 

Safe  havens 

Lanarka,  Cyprus 

Adana,  Turkey 

Repatriations  sites 

Montreal,  Canada 
Toronto,  Canada 

Chaloux  [8],  ten  ships  were  contracted  by  the  Government  of  Canada  for  a  total  cost  of  $24.7 
million  (2006  Canadian  dollars).  The  total  capacities  of  all  ships  was  20,071  people.  The 
observed  occupancy  rate  was  approximately  70%.  From  the  SHs,  the  CEPs  were  repatriated 
to  Canada  using  13  aircraft  contracted  by  the  DFATD,  which  flew  a  total  of  65  flights  to 
Montreal  and  Toronto.  For  this  part  of  the  repatriation,  the  occupancy  rate  and  cost  were 
estimated  to  78%  and  $35  million,  respectively  [8]. 

By  the  end  of  the  operation,  approximately  13,000  Canadians  were  evacuated  from  Lebanon 
via  the  Government  of  Canada’s  non-combatant  evacuation  operation  [4]  at  a  cost  of 
approximately  $2,700  per  person. 

STONE(Opt)  aims  to  provide  NEO  planners  a  better  understanding  of  the  potential  costs 
and  timelines  of  a  NEO  before  it  occurs,  as  well  as  the  ability  to  assess  the  cost  efficiency 
of  an  evacuation  after  the  operation  is  completed  (i.e.  assess  the  evacuation  strategy  post¬ 
mortem).  Within  the  context  of  the  Lebanon  2006  NEO,  this  may  have  entailed  optimizing 
the  schedule  and  number  of  contracted  ships,  for  example. 

While  STONE(Opt)  focuses  on  the  movement  of  CEPs  from  APs  to  ECs  to  SHs  (CEPs  in 
areas  of  potential  danger),  it  can  also  be  customized  to  consider  movement  from  SHs  to  RSs 
to  minimize  costs  (e.g.  minimize  number  of  aircraft  contracted) — however,  this  is  outside 
the  scope  of  the  present  Scientific  Report. 

Section  3  describes,  at  a  readable  level,  how  the  various  NEO  elements  are  mathematically 
modeled.  Followed-up  by  an  example  application  in  Section  4,  the  material  provides  insight 
as  to  how  NEO  planners  can  leverage  STONE(Opt)  to  determine  the  best  allocation  and 
utilization  of  resources,  and  estimate  an  evacuation  timeline. 
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3  Mathematical  modelling 


STONE(Opt)  was  developed  to  analyze  the  evacuation  process  described  in  Section  2.  The 
NEO  network  is  modelled  where  NEO  sites  (APs,  ECs,  SHs)  represent  nodes  and  the 
permissible  routes  of  CEP  movement  between  the  sites  are  represented  as  directed  arcs 
connecting  the  nodes.  Transporters  provide  the  movement  of  CEPs  between  NEO  element 
sites.  STONE(Opt)  determines  which  transportation  resources  to  assign  to  which  arcs  and 
at  what  time  in  order  to  move  the  CEPs  from  node  to  node  (and  finally  to  a  SH  node). 
Figure  6  enables  visualization  of  the  NEO  network  for  an  example. 

STONE(Opt)  is  time-based:  variables  keep  track  of  how  many  CEPs  are  at  what  state  (at 
a  site,  on  a  transporter,  etc.)  at  any  given  time.  The  user  specifies  a  time  period  (e.g.  two 
weeks)  and  time  step  granularity  (e.g.  six  hours)  and  the  NEO  process  is  modelled  one  time 
step  after  another:  variables  model  how  many  CEPs  arrive  where  and  when,  how  many  are 
transported  from  site  to  site  (and  when),  ultimately  leading  to  a  time  step  where  all  CEPs 
have  been  evacuated  to  a  safe  haven. 

3.1  Optimization 

STONE(Opt)  is  formulated  to  determine  the  required  number  and  schedule  for  transporters 
in  order  to  evacuate  CEPs  in  an  optimal  fashion.  What  constitutes  an  optimal  NEO  is 
multi-faceted  and  often  requires  NEO  planner  subject  matter  expertise,  but  is  simplified  as 
the  challenge  of  either: 

•  minimizing  the  duration  of  the  NEO; 

•  minimizing  the  average  time  CEPs  spend  in  the  areas  of  danger; 

•  minimizing  the  use  of  transporters  (both  the  number  required  and  their  number  of 
trips);  or 

•  a  combination  any  of  the  above. 

3.2  How  the  optimization  model  works 

The  NEO  network  model  is  formulated  as  an  integer  linear  problem.  An  integer  linear 
program  is  a  mathematical  optimization  or  feasiblity  program  in  which  a  subset  of  the 
variables  are  restricted  to  be  integers  and  the  constraints  are  linear  (i.e.  no  multiplication  of 
variables) .  It  is  an  extension  of  linear  programming  [22] ,  which  is  the  heart  of  operational 
research  and  whose  theory  was  developed  initially  for  military  applications.  The  popularity 
of  the  approach  is  due  to  the  ease  of  implementation,  modelling  flexibility,  and  availability 
of  solvers.  The  approach  caters  to  the  inclusion  of  custom  constraints  and  problem-specific 
features. 
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In  STONE(Opt),  mathematical  decision  variables  are  defined  to  model: 

•  the  number  of  CEPs  at  a  particular  site  at  a  particular  time; 

•  the  number  of  CEPs  moving  from  one  site  to  another  via  a  transporter  at  a  particular 
time; 

•  the  number  of  transporters  assigned  to  move  CEPs  from  a  site  to  another  site  at  a 
particular  time;  and 

•  the  number  of  trips  performed  by  a  transporter  for  a  particular  assigned  route  at  a 
particular  time. 

A  “trip”  is  the  movement  of  a  single  transporter  from  one  site  to  another  (transporting 
CEPs).  A  single  transporter  can  perform  multiple  trips  over  a  time  period  (taking  into 
account  return  travel  to  point  of  departure).  It  also  may  be  that  a  transporter’s  trip  spans 
multiple  time  periods.  The  time  for  a  transporter  to  complete  a  trip  from  one  site  to  the 
next  is  a  function  of  its  speed  and  the  route’s  distance  (rest  stops,  loading/unloading  times 
are  not  explicitly  modelled). 

The  assignment  of  transporters  to  routes  represent  the  main  decision  variables.  How  many 
CEPs  travel  on  any  particular  transporter  is  secondary.  The  relationships  between  the 
decision  variables  are  encoded  via  mathematical  formulae  (constraints)  and  secondary 
variables.  Given  the  required  inputs,  the  mathematical  model  formulated  is  solved  by  an 
integer  linear  programming  solver.  The  solver  applies  algorithms  to  determine  a  schedule 
for  transporters  to  evacuate  CEPs  in  an  optimal  fashion.  A  solution  to  a  particular  instance 
can  either  be  a  statement  of  infeasibility  (e.g.  cannot  complete  the  operation  in  ten  days 
without  violating  the  capacity  of  a  particular  site),  or  the  generation  of  an  optimal  schedule 
and  estimate  of  completion  time. 

3.3  Input  and  assumptions 

The  mathematical  model  developed  is  generic,  capturing  the  general  structure  and  elements 
of  a  NEO  while  maintaining  the  flexibility  to  represent  the  uniqueness  of  a  specific  NEO  case. 
Each  NEO,  modelled  within  STONE(Opt),  is  based  on  the  following  inputs,  assumptions, 
and  definitions: 

•  a  length  of  (e.g.  two  weeks)  and  appropriate  level  of  time  granularity  (e.g.  one  time 
step  equals  12  hours).  The  time  granularity  should  be  selected  to  be  insightful  yet  not 
to  prescriptive  (i.e.  modelling  down  to  single  minutes).  The  selection  of  appropriate 
time  granularity  is  key  for  solution  fidelity  and  may  affect  solver  running  time; 

•  the  list  of  the  APs,  ECs,  and  SHs,  as  defined  in  Section  2  and  respective  site  capacities 
(number  of  CEPs); 
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•  the  expected  CEP  processing  times6,  in  time  steps,  at  each  EC  (if  relevant  given  the 
granularity  specified); 

•  the  total  number  of  CEPs  to  be  evacuated  and  the  anticipated  arrival  rate  of  CEPs 
(number  of  CEPs  per  time  period)  to  each  AP  and  EC; 

•  the  network  specifying  the  possible  movement  of  CEPs  between  sites  (APs,  ECs,  SHs), 
specified  by  directed  edges  (routes)  and  distances  between  sites; 

•  a  list  of  available  transporters,  specifying  the  quantity,  speed  (e.g.  km/hr),  capacity 
(number  of  CEPs),  and  which  network  routes  each  transporter  can  be  employed  on; 
and 

•  optional  inputs  include  specifying  transporter  departure  times  along  specific  network 
routes,  minimum  or  maximum  utilization  rates  of  transporters,  or  time  periods  when 
transportation  is  not  permitted  or  times  when  sites  are  not  capable  of  accepting  further 
CEPs. 

STONE(Opt)  assumes  that  CEPs  remain  in  the  evacuation  network  once  they  enter  (no 
attrition).  If  no  further  transporters  are  available  from  a  site  at  a  given  time  period, 
then  CEPs  remain  at  the  site  until  the  next  available  transporter  can  depart  (potentially 
overnight). 

3.4  Constraints 

Constraints  are  primarily  driven  by  context  imposed  requirements,  site  capacities,  network 
routes,  and  the  availability  and  capacity  of  transporters.  Constraints  can  be  selectively 
applied  by  the  analyst  as  per  the  NEO  scenario  being  modelled.  Typically,  constraints  will 
include: 

•  all  CEPs  are  to  be  evacuated  to  SHs  by  a  user-specified  end  time  (e.g.  used  in 
conjunction  with  optimizing  transportation  resource  usage); 

•  the  number  of  CEPs  processed  or  accommodated  at  a  site  at  a  particular  time  period 
is  constrained  by  the  site’s  capacity  (if  specified); 

•  the  number  of  CEPs  departing  from  a  site  is  constrained  by  the  number  of  transporters 
available  and  their  capacities  and  utilization  rates;  and 

•  the  number  of  transporters  of  a  specific  type  being  used  at  a  given  time  must  be  less 
than  or  equal  to  the  limit  on  the  total  number  of  such  transporters  available. 

6  CEP  processing  time  represents  a  delay  between  arrival  and  possible  departure  of  a  CEP  at  a  site.  If 
the  time  granularity  is  greater  than  the  processing  time  (e.g.  12  hour  time  steps  compared  to  a  one  hour 
processing  time),  then  processing  time  is  not  modelled.  However  if  the  time  granularity  is  smaller  (e.g.  one 
hour  time  steps  and  two  hour  processing  times),  then  the  processing  time  is  modelled. 


DRDC-RDDC-2015-R074 


11 


Optional  constraints  include  fixing  the  number  of  trips  for  a  transporter  on  a  particular 
route  and  time,  specifying  time  periods  were  specific  sites  can  neither  accept  new  CEP 
arrivals  nor  let  CEPs  depart,  and  specifying  time  periods  when  resources  are  unavailable. 

Several  other  intuitive  “model”  constraints  are  also  implemented  to  ensure  the  proper 
accounting  of  CEPs  within  the  NEO  network.  For  example,  the  number  of  CEPs  arriving  a 
site  at  a  particular  time  corresponds  to  the  number  of  CEPs  arriving  on  their  own  to  that 
site  plus  any  CEPs  that  have  departed  from  other  sites  via  transporters  destined  for  that 
site — taking  into  account  transportation  time. 

3.5  Usage  and  limitations 

Section  4  provides  and  example  application  of  the  model  which  should  provide  the  reader 
with  greater  understanding  of  the  applications  of  STONE(Opt). 

The  selection  of  objective  function  (Section  3.1)  represent  the  different  usage  modes  of 
STONE(Opt).  Furthermore,  the  analyst  can  elect  to  apply  only  a  subset  of  the  constraints, 
or  to  fix  certain  decision  variables  (e.g.  require  a  specific  transporter  to  make  a  trip  at  a 
particular  time). 

As  CEP  arrival  rates  to  APs  or  ECs  are  a  source  of  variability,  one  of  the  benefits  of 
mathematical  modelling  is  the  ability  to  analyze  the  impact  of  changes  to  the  arrival  rates 
(e.g.  constant,  mad-rush,  wait-and-see),  both  in  terms  of  NEO  completion  time  and  resource 
requirements.  This  “what-if”  type  of  analysis  can  indeed  be  performed  using  STONE(Opt) 
by  creating  separate  model  runs  and  analyzing  the  differing  outputs.  For  example,  the 
analyst  can  compare  transportation  asset  usage  across  the  separate  runs.  That  being  said, 
comprehensive  examination  of  a  particular  solution  subject  to  input  variability  is  best 
accomplished  via  a  discrete  event  simulation  model. 

STONE(Opt)  is  focused  on  the  movement  of  people  from  assembly  points  onward  to  safe 
havens.  STONE(Opt)  does  not  explicitly  model  uncertainty  estimates  or  “error  bounds” 
associated  with  model  parameters.  STONE(Opt)  does  not  significantly  attempt  to  address 
or  optimize  resource  usage  and  related  procedural  detail  inside  each  NEO  location  (e.g. 
processing  of  CEPs  at  an  EC). 

Mathematical  details  of  the  formulation  are  presented  in  Annex  B  and  are  further  elab¬ 
orated  in  external  literature  [23].  The  formulation  was  implemented  in  Zimpl  [24] — the 
implementation  of  the  formulation  is  available  in  Annex  C.  Solutions  were  found  to  realistic 
problem  instances  (e.g.  examples  of  the  magnitude  of  the  2006  Lebanon  NEO,  considering 
approximately  15  days  with  half-day  time  granularity)  using  the  open-source  SCIP-SoPLEX 
integer  program  solver  [25,  26],  yielding  solutions  in  under  a  minute.  The  selection  of  time 
period  length  and  time  step  granularity  are  the  primary  drivers  of  the  problem  size  and  by 
extension  solution  time. 
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3.6  Comparison  to  other  models 


Section  2  stated  that  a  review  of  doctrine  showed  that  the  general  structure  and  elements 
of  a  NEO  are  very  similar  among  allied  nations.  It  is  anticipated  that  STONE(Opt) 
presented  herein  shares  analogies  with  a  model  developed  by  the  United  States  CAA  [10,  11]. 
Similarities  may  include  defining  variables  to  keep  track  of:  the  location  of  CEPs;  number 
of  transporters;  and  network-flow  constraints.  STONE(Opt)  enhancements  include: 

•  the  definition  of  trips  to  model  travel  time  of  transporters  spanning  multiple  time 
periods,  or  use  of  a  single  transporter  for  multiple  trips  within  a  single  time  period. 
This  enhancement  empowers  the  analyst  to  select  a  suitable  time  granularity  as  the 
situation  requires; 

•  enforcement  of  minimum/maximum  use  of  transporters’  capabilities.  This  enables 
specifying  desired  utilization  rates; 

•  different  usage  modes  to  facilitate  analysis  (e.g.  feasibility  of  a  plan,  optimization  of 
transportation  usage,  optimization  of  NEO  time,  etc.);  and 

•  development  using  readily  available  or  open-source  software  (Microsoft  Excel,  Zimpl, 
SCIP-SoPLEX)  enabling  cost-free  portability  and  code-sharing  amongst  partners. 
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4  Example  application 


In  this  section,  we  first  explain  how  STONE(Opt)  is  typically  run.  We  also  present  potential 
uses  of  STONE(Opt)  using  a  notional  scenario.  The  scenario  is  described  in  Section  4.2. 
The  types  of  questions  that  can  be  answered  and  the  kinds  of  analysis  that  can  be  conducted 
with  the  tool  are  presented  in  Section  4.3. 

4.1  Using  STONE(Opt) 

To  illustrate  how  STONE(Opt)  is  normally  run,  we  consider  its  four  main  planning  factors 
as  shown  in  Figure  2:  the  CEPs’  information,  the  sites,  the  transporters  and  the  evacuation 
time. 


JN 

CEPs 

(numbers  and 
location) 

t£ 

Sites 

(APs,  ECs,  SHs, 
and  capacity) 

i»l 

Transporters 

(types,  numbers 
and  schedules) 

(!) 

Time 

(to  evacuate 
all  CEPs) 

Figure  2:  Four  main  planning  factors  considered  in  the  STONE. 

To  run  STONE(Opt),  the  following  three  steps  are  normally  performed: 

1.  Specify 

•  the  data  related  to  the  sites  considered  in  the  evacuation  chain,  i.e.  the  list  of 
APs,  ECs  and  SHs,  their  respective  capacities  and  their  connections;  and 

•  the  information  about  the  CEPs,  including  their  numbers  and  locations  within 
the  affected  nation,  and  the  sites  to  which  they  are  expected  to  make  their  own 
way  to. 

2.  Set  one  of  the  following 

•  a  desired  total  evacuation  time  (i.e.  time  to  move  all  CEPs  to  safe  haven)  in  order 
to  determine  how  many  transporters  of  each  type  are  required  and  associated 
transport  schedules;  or 

•  the  types  and  numbers  of  transporters  available  to  estimate  the  expected  time 
required  to  conduct  the  evacuation. 

3.  Use  Microsoft  Excel  macros  or  Matlab  scripts  for  postprocessing  analysis  of  the  results 
produced  by  the  tool  to  get  a  more  comprehensive  picture.  For  example,  graphs  and 
tables  can  be  generate  to  answer  questions  such  as: 
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•  How  many  CEPs  at  specific  locations  as  a  function  of  time? 

•  How  many  trips  are  required  at  each  site? 

•  What  is  the  average  utilization  for  each  transporter?  and 

•  How  much  time  in  the  system  do  the  CEPs  spend? 

The  remainder  of  the  section  shows  how  STONE(Opt)  and  Steps  1  to  3  can  be  used  to 
analyze  a  scenario. 

4.2  Notional  scenario  description 

4.2.1  Population  areas  and  number  of  Canadian  or  eligible  persons 

We  consider  the  country  illustrated  in  Figure  3.  The  country  is  an  island  divided  into  17 
districts,  referred  to  as  Population  Areas  (PAs)  and  noted  PAoi,  PA02,  •  •  ■ ,  PA17.  The  total 
population  of  the  island  is  approximately  5,000,000  people  of  which,  7,400  are  CEPs. 


Figure  3:  Distribution  of  CEPs  across  the  17  PAs. 


Figure  3  also  depicts  the  distribution  of  CEPs  across  the  17  PAs,  where  red  represents  the 
areas  with  the  most  CEPs  and  green  represents  the  converse.  The  PAs  with  the  most  CEPs 
are  PA06  and  PA16  with  1,790  and  1,369  CEPs,  respectively,  while  PA10  is  the  least  populated 
with  only  40  CEPs.  The  exact  numbers  of  CEPs  in  each  PA  are  included  Figure  A. 3  of 
Annex  A  (Column  E). 
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4.2.2  Assembly  points,  evacuation  centres  and  safe  havens 


In  total,  there  are  21  assembly  points  (APoi,  AP02,  •  ■  • ,  AP21),  two  evacuations  centres  (EC01 
and  EC02)  and  one  safe  haven  (SH01)  considered  in  the  example.  The  locations  of  the  APs, 
the  ECs  and  the  SH  are  shown  in  Figure  4. 


Figure  4:  Assembly  points,  evacuation  centres  and  safe  havens. 


The  scenario  assumes  that  CEPs  leave  their  homes  (located  in  the  respective  PAs)  by  their 
own  means  to  get  to  an  AP.  Then,  they  are  transported  by  ground  to  one  of  the  two  ECs. 
Finally,  they  are  moved  by  sealift  from  the  EC  to  SHoi- 

The  network  of  connections  between  the  locations  is  represented  in  Figures  5  and  6.  For 
example,  AP13  receives  CEPs  coming  from  PA07  and  PA15.  EC02  is  used  to  process  CEPs 
coming  from  AP02,  AP03,  AP05,  APos,  AP09,  and  AP15  while  EC01  is  used  for  all  other  APs. 

In  addition,  the  model  handles  CEPs  who  go  directly  to  an  EC  (on  their  own)  with¬ 
out  going  through  an  AP.  This  was  not  explicitly  illustrated  in  Figure  5  to  reduce  the 
clutter  (i.e.  more  connections  between  PAs  and  ECs).  So,  we  also  assumed  that  CEPs 
in  PA04,PAo6,PAo7,PAo8,PAio,PAi3,PAi4,PAi5,PAi6  and  PA17  will  go  to  EC0i,  those  in 
PAoi,PAo3,PAo9,PAh  and  PA12  will  go  EC02,  while  those  in  PA02  and  PA05  will  go  to 
either  one  of  the  two  ECs.  For  the  purpose  of  the  example,  the  percentage  of  CEPs  going 
directly  from  a  PA  to  an  EC  is  estimated  at  20%.  As  an  example,  it  is  expected  that 
approximately  152  CEPs  in  PA01  (80%  of  190  CEPs)  would  go  to  AP05  while  the  other  38 
CEPs  (20%  of  190  CEPs)  would  get  to  EC02  on  their  own.  This  is  shown  in  columns  E  to  K 
in  Figure  A. 3  (Annex  A). 
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Figure  5:  Connections  between  PA,  AP,  EC,  and  SH  sites. 


Figure  6:  Connections  between  AP,  EC,  and  SH  sites. 
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4.2.3  Transport  types 


Two  transport  types,  presented  in  Table  3,  are  considered  in  this  example.  For  the  ground 
transportation  between  the  APs  and  the  ECs,  the  scenario  includes  the  use  of  buses  with  a 
maximum  capacity  of  40  CEPs.  The  movement  of  CEPs  between  the  ECs  and  SHoi  is  done 
by  ferries  with  a  capacity  of  200  CEPs.  The  minimum  utilization  is  set  to  0.66  for  both 
transport  types,  meaning  the  all  bus  and  ferry  trips  are  required  to  fill  up  to  a  minimum  of 
27  and  132  CEPs,  respectively,  prior  to  departure7.  Speeds  of  75  km/h  for  the  buses  and  20 
km/h  for  the  ferries  are  assumed  in  the  scenario.  The  speed  values  are  used  to  calculate  the 
maximum  number  of  trips  that  the  transport  resources  can  accomplish  within  a  time  step. 


Table  3:  Transport  types  considered  in  the  example. 


ID 

Name 

Description 

Number 

Available 

Capacity 

Speed 

(km/h) 

Min/Max 

Utilization 

TTr 

Bus 

Between  AP  and  EC 

13 

40 

75 

0.66  /  1.00 

tt2 

Ferry 

Between  EC  and  SH 

5 

200 

20 

0.66  /  1.00 

4.3  Potential  uses 

4.3.1  Number  of  transport  resources  required  versus  desired  evacuation  time 

NEO  planners  are  interested  in  estimating  how  many  transport  resources  would  be  required 
to  evacuate  all  CEPs  as  a  function  of  a  desired  evacuation  time.  Intuitively,  if  the  objective 
is  to  move  7,400  CEPs  like  in  this  example,  more  transporters  would  be  needed  if  one  wants 
to  achieve  the  evacuation  in  5  days  versus  10  days.  But  how  many  transport  resources? 
Figure  7  shows  the  number  of  each  transport  type  (i.e.  bus  in  blue  and  ferry  in  red)  required 
as  a  function  of  the  desired  evacuation  time.  To  arrive  at  this  figure,  the  number  of  days  to 
evacuate  CEPs  was  varied  between  5  and  15  with  an  increment  of  1,  assuming  the  CEPs 
evacuate  in  an  orderly  fashion 8.  The  lines  show  how  many  transport  resources  on  average 
are  required  per  day  (the  sum  of  transportation  resources  required  per  day  divided  by  the 
number  of  days).  For  instance,  the  results  indicate  that  in  order  to  evacuate  all  CEPs  in  8 
days,  an  average  of  14.3  buses  and  5.8  ferry  would  be  required  every  day.  As  expected,  the 
average  number  of  transporters  required  per  day  decreases  as  the  desired  evacuation  time 
increases. 

The  numbers  in  Figure  7  represent  averages,  which  means  that  using  those  exact  numbers 
of  transport  resources  would  not  be  sufficient  to  evacuate  all  CEPs  in  the  desired  time — not 
providing  enough  transport  capacity  to  meet  the  peaks  and  valleys  (the  number  of  CEPs 
who  are  moved  every  day  is  not  necessarily  constant  as  it  may  vary  through  time).  However, 
such  a  figure  can  be  used  by  planners  to  determine  whether  or  not  a  plan  is  feasible  in  a  best 

'  If  the  minimum  utilization  were  set  to  zero,  then  some  buses  might  go  with  only  one  CEP  in. 

8  As  discussed  in  Scheer  [14],  orderly  fashion  refers  to  a  constant  CEPs’  departure  rate  (from  their  home). 
For  instance,  if  a  PA  has  a  total  100  CEPs  and  the  plan  consists  of  an  evacuation  in  ten  days,  then  an 
average  of  10  CEPs  will  leave  their  home  every  day  for  an  AP  or  an  EC.  From  a  planning  purpose,  this 
corresponds  to  the  ideal  case. 
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Figure  7:  Number  of  transport  resources  as  a  function  of  evacuation  time. 


case  scenario.  For  example,  it  would  be  unrealistic  to  think  that  all  CEPs  can  be  evacuated 
in  8  days  if  only  10  buses  and  4  ferries  were  available  to  execute  a  plan.  On  the  other  hand, 
the  figure  indicates  that  this  quantity  of  transport  resources  could  provide  evacuation  of  all 
CEPs,  in  a  best  case  scenario,  over  a  14  day  period,  or  longer. 

4.3.2  Feasibility  of  evacuation  timeline  given  specific  number  of  transport 
resources  and  sites’  capacity 

Given  an  estimate  of  the  number  of  transporters  available,  it  is  possible  to  use  the  tool  to 
determine  a  realistic  evacuation  timeline.  In  the  current  example,  we  assumed  that  the  plan 
includes  13  buses  and  5  ferries  (see  Table  3).  Figure  7  suggests  that  with  13  buses  and  5 
ferries  available,  the  evacuation  of  all  7,400  CEPs  should  be  possible  in  10  days  or  more. 
STONE(Opt)  was  run  to  confirm  that  an  evacuation  is  indeed  achievable  in  10  days. 

The  second  important  aspect  to  consider  is  the  sites’  capacity,  in  particular,  “do  the  sites 
reach  maximum  capacity  during  the  evacuation  process  and  for  how  long?”  In  practice,  the 
key  sites,  mainly  the  ECs  and  the  SHs,  are  surveyed  to  determine  the  maximum  number  of 
CEPs  that  can  be  held  and  serviced  at  one  time.  From  a  planning  perspective,  the  objective 
is  to  develop  an  evacuation  plan  that  would  satisfy  the  capacity  of  the  sites  used  during  the 
evacuation.  The  capacity  here  refers  to  the  maximum  holding  capacity  in  terms  of  people 
(i.e.  CEPs)  that  each  site  can  accommodate. 
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For  illustration  purpose,  we  focus  on  ECoi  which  is  assumed  to  have  a  capacity  of  375 
CEPs.  Figures  8a,  8b  and  8c  show  the  projected  number  of  CEPs  at  ECoi  as  a  function 
of  time  based  on  a  desired  evacuation  time  of  10,  11  and  12  days,  respectively.  The  red 
lines  represent  the  site  capacity  of  375  CEPs.  The  bars  denotes  the  number  of  CEPs  at  the 
location  at  the  end  of  each  time  period.  In  all  three  cases,  we  used  an  orderly  (i.e.  constant) 
arrival  rate  of  CEPs  over  the  first  n  —  2  days,  where  n  represents  the  desired  evacuation 
time  (10,  11  or  12  days). 

Figure  8  suggests  that  planning  to  complete  the  evacuation  in  12  days  is  preferable  when 
accounting  for  the  capacity.  The  results  show  that  for  an  evacuation  in  10  days,  the  capacity 
of  ECoi  would  be  exceeded  approximately  40%  of  the  time  (8  time  periods  out  of  20),  i.e. 
on  time  periods  “Day  2  -  AM”,  “Day  3  -  AM”,  “Day  3  -  PM”,  “Day  4  -  AM”,  “Day  5  - 
AM”,  “Day  7  -  AM”,  “Day  7  -  PM”  and  “Day  8  -  PM”.  This  includes  a  total  of  almost  600 
CEPs  at  once  on  time  period  “Day  5  AM”,  which  is  160%  of  the  capacity  of  the  site.  For 
an  evacuation  in  11  days,  the  capacity  is  exceeded  approximately  18%  of  the  time  (4  time 
periods  out  of  22),  with  a  maximum  of  more  than  500  CEPs  on  time  period  “Day  9  -  AM”. 
On  the  other  hand,  Figure  8c  indicates  that  for  the  evacuation  in  12  days,  the  capacity  is 
exceeded  for  a  single  time  period  (i.e.  “Day  9  -  PM”)  and  only  by  10  CEPs.  It  is  however 
important  to  note  that  because  the  time  step  used  here  is  relatively  large  (i.e.  half-day),  the 
estimate  of  whether  the  number  of  CEPs  exceed  the  sites’  capacity  should  be  contextualized. 
The  exact  number  of  CEPs  are  estimated  at  the  beginning  and  at  the  end  of  each  time  step, 
but  the  variation  of  CEPs  in  between  these  points  in  time  remains  unknown. 

4.3.3  Transport  resources  utilization 

Once  the  plan  is  set  on  the  number  of  transporters  available  and  on  the  desired  evacuation 
time,  more  in-depth  analysis  on  the  utilization  of  transport  resources  can  be  performed. 
To  illustrate  this  functionality,  we  consider  an  evacuation  time  of  12  days  with  13  buses 
and  5  ferries.  Table  4  shows  the  total  number  of  trips  and  the  average  resource  utilization 
forecasted  with  the  notional  scenario. 

Table  4:  Projected  total  number  of  trips  and  utilization  for  both  transport  types. 


ID 

Name 

Number  of  trips 

Utilization  rate 

TTi 

Bus 

188 

77.57% 

tt2 

Ferry 

46 

79.91% 

Table  4  provides  overall  summary  but  the  data  can  also  be  broken  down  by  individual  day. 
The  blue  bars  in  Figures  9a  and  9b  show  the  projected  number  (Nbr)  of  buses  and  ferries 
required  per  day.  The  red  dots  in  the  figures  represent  the  number  of  trips  (or  departures) 
forecasted.  For  instance,  in  the  morning  of  Day  3,  11  of  the  13  buses  are  required  and  the 
total  number  of  trips  is  9  (Figure  9a).  For  the  same  period,  all  5  ferries  are  busy  and  there 
are  only  2  ferry  trips  (Figure  9b).  The  number  of  resources  required  may  exceed  the  number 
of  trips  because  the  time  needed  for  a  trip  could  be  more  than  a  time  step.  This  is  the  case 
here  where  the  ferry  transit  time  (roundtrip)  is  more  than  a  half-day,  which  is  the  time  step 
used  in  this  scenario. 
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4.3.4  Allocate  transport  resources  and  building  schedule 


The  number  of  trips  and  number  of  transporters  required  on  any  given  day  can  also  be 
broken  down  by  location.  For  example,  Table  5  depicts  the  number  of  buses  required  per 
day  at  AP09,  APi§  and  AP19  as  computed  with  STONE(Opt).  The  distribution  of  ferries 
and  associated  trips  are  also  included  for  both  ECs.  The  numbers  in  parenthesis  represent 
the  number  of  trips  departing  the  location. 

Such  information  can  be  used  to  help  planners  building  preliminary  transport  schedule.  For 
instance,  the  table  shows  that  one  bus  should  be  allocated  to  APis  from  Day  1  to  Day  10. 
The  bus  would  have  to  conduct  two  trips  per  day — one  in  the  morning  and  one  in  the 
afternoon.  On  the  other  hand,  AP09  would  not  need  a  full-time  dedicated  bus  because  only 
two  trips  are  required  at  that  location  to  move  the  CEPs  to  its  associated  EC. 

For  the  ferries,  STONE(Opt)  results  indicate  that  for  most  days,  four  ferries  should  be 
allocated  to  EC01,  he.  from  Day  2  to  Day  8.  On  Day  9,  one  ferry  at  EC01  should  move  to 
EC02  to  meet  the  higher  demand  expected  on  Days  9  to  11. 

This  is  a  relatively  simple  scenario  with  only  two  ECs  and  one  SH.  However,  it  illustrates 
how  the  output  data  from  STONE(Opt)  can  be  used  to  inform  NEO  planners  on  number 
of  transport  resources  and  trips,  and  therefore  help  building  resource  schedule  that  can  be 
later  implemented  in  a  real-life  scenario. 
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Figure  8:  Number  of  CEPs  as  a  function  of  time  at  ECoi  for:  a)  an  evacuation  in  10  days; 
b),  an  evacuation  in  11  days;  and  c)  an  evacuation  in  12  days. 
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Bus 


Ferry 


Figure  9:  Number  of  transport  resources  and  trips  projected  per  day  for:  a)  buses  (TT\); 
and  b)  ferries  (TT2). 
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Table  5:  Number  of  transport  resources  and  trips  (in  parenthesis)  required  at  specific 
locations. 


Assembly  points 

Evacuation  centres 

Day 

AP09 

AP 18 

APig 

Total** 

ECoi 

EC02 

Total 

1 

AM 

- 

1(1) 

1(1) 

4(4) 

- 

- 

- 

PM 

- 

1(1) 

1(1) 

8(7) 

1(1) 

- 

1(1) 

2 

AM 

- 

1(1) 

1(1) 

11  (9) 

3(2) 

— 

3(2) 

PM 

- 

1(1) 

1(1) 

11  (8) 

4(2) 

1(1) 

5  (3) 

3 

AM 

- 

1(1) 

1(1) 

11  (9) 

4(2) 

1  (0) 

5(2) 

PM 

- 

1(1) 

1(1) 

13  (12) 

4(2) 

- 

4(2) 

4 

AM 

- 

1(1) 

1(1) 

13  (8) 

4(2) 

1(1) 

5(3) 

PM 

- 

1(1) 

1(1) 

12  (10) 

4(2) 

1  (0) 

5  (2) 

5 

AM 

- 

1(1) 

1(1) 

13  (10) 

4(2) 

1(1) 

5(3) 

PM 

1(1) 

1(1) 

1(1) 

11  (8) 

4(2) 

1  (0) 

5  (2) 

6 

AM 

- 

1(1) 

1(1) 

12  (10) 

3(1) 

1(1) 

4(2) 

PM 

- 

1(1) 

1(1) 

13  (10) 

3(2) 

1  (0) 

4(2) 

7 

AM 

- 

1(1) 

1(1) 

13  (9) 

4(2) 

1(1) 

5(3) 

PM 

- 

1(1) 

1(1) 

11  (8) 

4(2) 

1  (0) 

5  (2) 

8 

AM 

- 

1(1) 

1(1) 

13  (11) 

4(2) 

- 

4(2) 

PM 

- 

1(1) 

- 

12  (7) 

4(2) 

1(1) 

5  (3) 

9 

AM 

- 

1(1) 

1  (2) 

11  (9) 

3(1) 

2(1) 

5(2) 

PM 

- 

1(1) 

- 

12  (11) 

3(2) 

1  (0) 

4(2) 

10 

AM 

- 

1(1) 

1  (2) 

9(6) 

3(1) 

- 

3(1) 

PM 

1(1) 

1(1) 

- 

13  (12) 

2(1) 

1(1) 

3(2) 

11 

AM 

- 

- 

1(1) 

11  (5) 

3(2) 

2(1) 

5(3) 

PM 

- 

- 

- 

8(5) 

3(1) 

1  (0) 

4(1) 

12 

AM 

- 

- 

- 

2(0) 

2(1) 

- 

2(1) 

PM 

- 

- 

- 

- 

1  (0) 

- 

1(0) 

Total:  13  (188)  Total:  5  (46) 


**Note  that  this  total  is  calculated  across  all  APs  and  not  just  APog,  APis  and  APig. 
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4.3.5  Movement  of  CEPs  from  safe  heavens  to  repatriation  sites 


The  CEP  evacuation  process  modeled  in  this  Scientific  Report  begins  at  the  population  area 
and  ends  at  the  safe  havens.  In  general,  the  objective  of  the  model  is  to  move  all  CEPs  to 
the  safe  havens  in  the  minimum  amount  of  time  and  within  the  transport  resources  available. 
The  movement  of  the  CEPs  to  the  final  destination,  i.e.  a  repatriation  site,  is  not  explicitly 
considered.  In  some  scenarios,  the  safe  havens  may  be  the  same  as  the  repatriation  sites, 
but  this  is  rarely  the  case.  For  instance,  in  2006  during  Op  LION,  more  than  13,000  CEPs 
were  evacuated  from  Lebanon  by  sea  to  two  safe  haven  locations  (in  Turkey  and  Cyprus) 
before  being  repatriated  to  Canada  (Montreal  and  Toronto)  by  airlift  [6]. 

Even  if  the  repatriation  sites  are  not  directly  accounted  for  in  this  current  version  model, 
number  of  assets  required  to  repatriate  the  CEPs  can  be  estimated  by  doing  post-analysis 
of  output  data  generated  by  the  tool.  In  particular,  the  model  outputs  include  the  number 
of  CEPs  arriving  at  the  safe  havens  as  a  function  of  time.  Table  6  shows  how  many  CEPs 
arrive  every  day  at  the  safe  haven  for  the  scenario  considering  13  buses  and  5  ferries,  and  an 
evacuation  in  12  days. 

Table  6:  Number  of  CEPs  arriving  at  safe  haven  as  a  function  of  time. 


Day 

AM 

PM 

Total 

1 

0 

0 

0 

2 

200 

483 

683 

3 

446 

299 

745 

4 

351 

482 

833 

5 

274 

456 

730 

6 

340 

335 

675 

7 

380 

407 

787 

8 

319 

270 

589 

9 

515 

332 

847 

10 

349 

200 

549 

11 

348 

524 

872 

12 

146 

145 

291 

For  illustration  purpose,  we  assume  here  that  the  CEPs  are  moved  to  the  repatriation  site  by 
airlift.  The  numbers  in  Table  6  can  be  used  to  estimate  the  entire  evacuation  timeline  given 
a  certain  flight  schedule  from  SHoi  to  Canada.  Consider  the  notional  schedule  shown  in 
Table  7,  which  consists  of  four  flights  a  day  (two  in  the  morning  and  two  in  the  afternoon), 
every  other  day,  starting  on  Day  3  and  ending  on  Day  13. 

Figure  10  shows  the  number  of  CEPs  in  the  danger  zone  (red  line)  and  at  repatriation  site 
(green  line)  as  a  function  of  time.  We  assumed  that  each  scheduled  flight  can  carry  up  to  400 
CEPs.  CEPs  in  the  danger  zone  refers  to  the  total  CEPs  who  are  either  still  at  their  home 
(but  planning  to  evacuate),  at  an  AP  or  at  an  EC.  This  can  be  estimated  using  Table  6. 
The  green  line  shows  that  given  the  schedule  provided  in  Table  7,  the  last  CEPs  repatriated 
to  Canada  occurs  on  Day  13.  The  schedule  includes  24  flights,  for  a  total  capacity  of  9,600 
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Table  7:  Notional  flight  schedule  from  SHqi  to  repatriation  site. 


Number  of  departures 

Day 

AM 

PM 

3 

2 

2 

5 

2 

2 

7 

2 

2 

13 

2 

2 

CEPs.  Considering  that  all  7,401  CEPs  are  repatriated,  this  corresponds  to  a  utilization  rate 
of  approximately  77%.  This  example  uses  a  notional  schedule  to  demonstrate  how  output 
from  the  model  can  be  used  to  analysis  the  repatriation  process.  Many  different  schedules 
can  be  tested.  Additionally,  similar  to  the  way  that  the  movement  of  CEPs  between  PAs 
and  APs,  and  between  APs  and  ECs  is  optimized,  it  would  be  possible  to  optimize  the  CEPs 
repatriation,  i.e.  the  movement  of  CEPs  from  the  SHs  to  the  repatriation  site. 


Figure  10:  Number  of  CEPs  in  danger  area  and  at  repatriation  site  as  a  function  of  time. 
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4.4  Discussion 


The  analyses  discussed  in  this  section  are  not  exhaustive  but  provide  a  representative  sample 
of  the  types  of  questions  that  can  be  answered  using  STONE(Opt)  in  support  of  high  level 
NEO  planning  efforts. 

It  should  be  noted  that  there  are  many  other  questions  that  STONE(Opt)  presented  herein 
cannot  answer.  For  example,  “what  is  the  queue  size  a  specific  location?”,  “how  much 
time  each  CEPs  spend  in  the  system?”,  or  “how  long  does  the  CEPs  spend  in  the  whole 
system  or  a  specific  location?”  These  types  of  questions  require  modelling  at  a  lower  level  of 
granularity. 

Hence,  the  natural  extension  to  optimization  modelling  is  the  development  of  a  DES  to 
simulate  the  operation  allowing  to  perform  “what-if”  type  analysis,  model  uncertainty, 
evaluate  various  courses  of  action,  and  estimate  queue  size  and  time  spent  by  evacuees  in 
the  system  and  at  specific  locations.  Many  of  these  aspects  are  incorporated  in  the  other 
elements  of  the  STONE  as  explained  in  Section  1.3. 
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5  Summary  and  future  work 


The  NEO  modelling  toolset  called  STONE  that  is  being  developed  by  the  CJOC  OR&A 
Team  comprises  of  three  main  components: 

1.  Visualization  -  to  provide  situational  awareness  by  quickly  and  automatically  creating 
maps  showing  the  sites  locations  and  the  connectivity  between  them  in  the  form  of 
map  layers; 

2.  Optimization  -  a  mathematical  model  (STONE(Opt))  to  help  determine  best  allocation 
and  utilization  of  resources  and  estimate  evacuation  timeline;  and 

3.  Simulation  -  a  discrete  event  simulation  (DES)  to  simulate  the  operation  allowing  to 
perform  “what-if”  type  analysis,  model  uncertainty,  evaluate  various  courses  of  action, 
and  estimate  queue  size  and  time  spent  by  evacuees  in  the  system  and  at  specific 
locations. 

This  Scientific  Report  documents  the  elements  of  the  mathematical  optimization  model 
named  STONE(Opt)  and  presents,  using  a  notional  scenario,  examples  of  questions  that 
can  be  answered  and  types  of  analysis  that  can  be  conducted  with  the  model. 

The  development  of  a  DES  to  simulate  NEO  is  a  natural  extension  to  the  optimization  model 
presented  in  this  document.  This  work  is  planned  as  part  of  the  Operational  and  Strategic 
Research  and  Analysis  Support  to  CJOC  project  of  the  ADM(S&T)  Force  Employment 
portfolio. 

In  November  2014  the  CJOC  OR&A  Team,  accompanied  by  CJOC  J5  NEO,  presented 
STONE  to  the  Director  Policy,  Partnerships  and  Governance,  and  the  Deputy  Director  of 
Emergency  Planning,  DFATD.  Action  items  identified  include: 

1.  application  of  STONE  on  high-risk  missions  identified  by  DFATD;  and 

2.  development  of  STONE(DES)  to  model  ECs  is  greater  detail  (with  sub-processes)  in 
order  to  facilitate  answering  questions  such  as  “how  many  personnel  are  required  to 
process  CEPs  in  a  given  time  period?” 

5.1  International  collaboration 

Cooperation  between  friendly  countries  is  very  important  but  also  adds  to  the  complexity 
as  each  nation  attempts  to  evacuate  their  citizens  but  while  competing  for  the  same  support 
and  resources  (e.g.  transporters,  assembly  points/evacuation  centres). 

In  2014  a  NATO  STO  SAS  technical  activity  was  initiated  by  Defence  Research  &  De¬ 
velopment  Canada  (DRDC)  Centre  for  Operational  Research  and  Analysis  (CORA)  [17] 
to  enable  NATO,  NATO  Partnership  for  Peace,  and  NATO  Global  Partners  countries  to 
collaborate  in  OR&A  support  to  NEO.  The  purpose  of  this  activity  is  to  develop  and 
maintain  a  cohesive  OR&A  community  to  support  the  planning  of  the  NEO  Coordination 
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Group  (NCG).  The  NCG  consists  of  military  planners  and  foreign  affairs  representatives 
of  nineteen  member  nations,  fourteen  of  which  are  NATO  or  Partnership  for  Peace  (PfP) 
members  (Austria,  Belgium,  Canada,  Denmark,  France,  Germany,  Italy,  Norway,  Portugal, 
Spain,  Sweden,  The  Netherlands,  United  Kingdom,  United  States  of  America)  and  two 
NATO  Global  Partners  (Australia,  New  Zealand).  Switzerland,  Cyprus,  and  the  European 
Union  (European  External  Action  Service)  are  the  other  NCG  participants  not  affiliated  with 
NATO.  The  NCG  meets  twice  annually  to  coordinate  NEO  planning  efforts  and  share  best 
practice.  The  main  objective  of  the  scientific  collaboration  is  to  support  and  complement 
the  NCG  efforts.  Collaboration  areas  to  be  explored  include: 

•  tools,  models,  analyses  undertaken  by  OR&A  teams  supporting  military  planners  in 
the  planning  of  NEOs;  and 

•  establishment  of  a  network  of  operational  analysts  supporting  military  planners  in 
planning  of  NEOs  facilitating  data  sharing,  promoting  cohesion  in  analysis  and  increase 
situational  awareness  of  resource  constraints  and  problem  commonalities. 

The  efforts  of  this  SAS  activity  is  expected  to  influence  the  development  and  applications  of 
STONE. 
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Annex  A:  Instructions  and  graphical  user  interface  for 
STONE(Opt) 


This  annex  presents  technical  data  related  to  STONE  optimization  component,  referred  to 
as  the  STONE(Opt),  including  the  setup  instructions,  the  directories  and  files  structure,  the 
main  requirement  needed  to  run  the  tool,  and  an  overview  of  the  GUI  functionalities. 

A.1  Setup  instructions  and  requirements 

There  are  no  specific  installation  instructions  required  since  STONE(Opt)  is  a  self-contained 
package.  All  that  is  required  is  the  use  of  the  directories  and  files  structure  presented 
in  Figure  A.l.  Note  that  all  the  files  needed  to  run  STONE(Opt)  are  available  from  the 
authors. 


InputData . xlsm 

Templates  <DIRECTORY> 

NEO_Opt_Formulation . zpl 

ScipCommands .dat 

ProcessScipBatch.bat 

scip302 . exe 

DataFiles  <DIRECTORY> 

Arrival .dat 

SafeHavens .dat 

AssemblyPoints . dat 

SiteCapacities . dat 

Blackout . dat 

Timelnterval . dat 

EvacuationCentres .dat 

TransportArcs . dat 

FixedTimeTransportArcs .dat 

TransportersType . dat 

Figure  A.l:  Directories  and  dies  structure. 


The  file  InputData.xlsm  is  the  GUI,  developed  in  Microsoft  Excel  and  Visual  Basic  for 
Applications.  It  is  detailed  in  Section  A. 2. 

The  directory  Templates  includes  the  four  files  required  to  run  the  SCIP-SoPLEX  integer 
program  solver.  The  file  NEO_Opt_Formulation.zpl  contains  the  mathematical  formulation 
and  is  included  for  completeness  in  Annex  C.  The  file  ScipCommands.dat  is  a  parameter 
file  read  by  the  SCIP-SoPLEX  solver.  The  file  specifies  which  formulation  file  to  read 
(NEO_Opt_Formulation.zpl),  the  solver  time  limit  in  seconds,  and  where  to  write  the 
solution  output  (ScipOutput.dat).  The  formulation  file  reads  in  a  series  of  ten  “.dat”  files 
specifying  instant-specific  inputs  and  optimization  parameters.  The  “.dat”  files  represent  the 
user-specified  problem  to  be  solved.  Although  the  user  has  the  option  to  create  the  “.dat” 
files  manually,  they  are  typically  auto-generated  by  the  GUI  (the  Microsoft  Excel  file)  based 
on  input  parameters  provided  by  the  user  (details  in  Section  A. 2).  Once  generated,  they  are 
automatically  put  in  the  directory  Datafiles.  The  format  of  the  “.dat”  files  is  discussed 
later  in  the  annex. 
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The  file  ProcessScipBatch.bat  is  a  Windows  batch  hie  that  invokes  SCIP-SoPLEX  solver9 
with  parameter  hie  ScipCommands.dat  and  then  parses  the  solution  file  (ScipOutput.dat) 
via  the  Windows  powershell  scripting  language.  Details  of  the  parsing  process  are  provided 
in  Section  A. 4. 

A.2  Graphical  user  interface 

As  mentioned  previously,  the  “.dat”  files  required  by  the  SCIP-SoPLEX  integer  program 
solver  can  be  created  manually  by  the  user.  However,  this  process  is  prone  to  errors  due 
to  the  number  of  variables  and  constraints  that  a  typical  problem  contains.  To  ease  this 
process,  a  GUI  has  been  built  in  Microsoft  Excel  to  capture  the  inputs  from  the  user.  Input 
data  is  then  automatically  converted  in  the  “.dat”  files  in  the  appropriate  format.  The  GUI 
contains  the  following  eight  worksheets: 

•  Simulationlnf ormation; 

•  PopulationAreas; 

•  AssemblyPoints; 

•  EvacuationCentres; 

•  SafeHavens; 

•  Di st Matrix; 

•  TransportTypes;  and 

•  FixedTransport. 

Each  of  them  is  described  below. 

A.2.1  Worksheet  Simulationlnformation 

The  worksheet  Simulationlnformation  is  shown  in  Figure  A.2. 

The  green-shaded  cells  in  the  tool  (e.g.  cells  E2,  E3,  F3,  E4,  E5,  E6  and  F6  in  Figure  A.2) 
represent  parameters  that  must  be  specified  by  the  user.  The  six  parameters  that  must  be 
entered  in  this  worksheet  are  described  in  Table  A.l. 


9  The  executable  scip302.exe  can  be  obtained  from  http://scip.zib.de/. 
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D 

E 

F 

Optimization 

Timestep 

2  hours 

Duration  (in  days)  •  Target  /  Model 

12 

12 

Folder  Name 

DataFiles 

Optimization  Objective 

2  -  Average  time  in  system 

Timestep  CEP  Arrival  (From  /  To) 

3 

9 

7 

1)  Create  Data  Files 

8  _ 

9 

2)  Run  Optimization 

10  - 

“ll  3)  Create  Transport  Schedule 

12  - 

Figure  A. 2:  Graphical  user  interface  -  main  worksheet. 


The  worksheet  also  includes  the  following  action  buttons: 

•  Create  Data  Files  -  as  its  name  suggests,  this  button  is  used  to  auto-generate  the 
ten  “.dat”  files.  If  clicked,  the  application  reads  the  input  data  entered  by  the  user  in 
the  different  worksheets,  converts  the  data  in  the  “.dat”  hies,  and  saves  them  in  the 
directory  “DataFiles”  (or  whatever  directory  name  given  by  the  user  in  cell  E4). 

•  Run  Optimization  once  the  “.dat”  hies  have  been  generated,  either  automatically 
using  the  “Create  Data  Files”  button  or  manually  by  the  user,  the  SCIP-SoPLEX 
integer  program  solver  can  be  called  by  clicking  the  “Run  Optimization”  button. 
This  process  may  take  some  time  as  the  problems  to  solve  can  be  quite  large.  The 
optimization  process  will  terminate  if  either  a)  the  solver  hnds  the  optimal  solution, 
or  b)  a  time  limit  is  reached.  In  the  latter  case,  the  best  solution  found  is  returned. 
The  time  limit  is  set  by  default  to  300  seconds,  but  it  can  be  changed  in  the  hie 
ScipCommands.dat.  The  solver  can  also  be  launched  manually  outside  the  GUI  by 
clicking  on  the  hie  ProcessScipBatch.bat  (in  Windows  Explorer).  However,  for  this 
to  work,  the  four  hies  in  the  directory  Templates  must  hrst  be  copied  in  the  directory 
DataFiles  with  the  ten  “.dat”  hies. 

•  Create  Transport  Schedule  -  it  allows  the  user  to  view  partial  results  produced 
by  STONE(Opt).  Once  the  button  is  pressed,  a  worksheet  named  OptTransport  is 
populated  showing  the  expected  number  of  assets  and  the  number  of  trips  required 
(by  individual  resource  type,  e.g.  ferry)  at  each  time  step  extracted  from  the  solution 
found.  The  “Create  Transport  Schedule”  button  is  typically  used  as  a  means  for 
debugging  and  validation  as  it  provides  a  quick  overview  at  a  glance  of  the  number 
of  transportation  resources  required.  We  recommend  to  develop  more  sophisticated 
postprocessing  analysis  scripts  to  get  a  more  comprehensive  picture  of  the  results 
calculated  by  STONE(Opt).  This  is  discussed  further  in  Section  A. 4. 
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Table  A.l:  Input  parameters  in  worksheet  Simulationlnformation. 


Cell  Description 

Time  step  E2 


Duration  —  Target 

E3 

Duration  —  Model 

F3 

Folder  Name 

E4 

Optimization  Objective 

E5 

Time  step  CEP  Arrival  (From)**  E6 
Time  step  CEP  Arrival  (To)**  F6 


The  level  of  time  granularity.  Possi¬ 
ble  values  from  a  dropdown  list  are 
“24  hours,  ”,  “12  hours”,  “8  hours”,  “6 
hours”,  “4  hours”,  “3  hours”  and  “2 
hours”. 

Target  length  of  NEO  (in  days) . 

Total  number  of  days  to  be  modelled. 
Name  of  the  directory  containing  the 
“.dat”  files.  The  recommended  value  is 
“Datafiles”. 

The  desired  optimization  type  picked 
from  a  dropdown  list  with  the  following 
potential  values: 

1  -  Minimum  number  of  days 

2  -  Average  time  in  system 

3  -  Minimize  capacity  flow 

4  -  Minimize  transport  usage 

5  -  Total  number  or  trips. 

First  time  step  in  a  day  when  CEPs  are 
expected  to  arrive. 

Last  time  step  in  a  day  when  CEPs  are 
expected  to  arrive. 


**For  example,  if  the  time  step  is  “2  hours”,  and  the  time  step  CEP  arrival  from  and  to 
values  are  3  and  9,  respectively,  then  it  means  that  in  the  particular  scenario,  the  CEPs 
are  expected  to  arrive  at  the  APs  and  ECs  between  0600  and  1800  every  day  (i.e.  at  time  steps 
3,  4,  5,  6,  7,  8,  9  (Day  1),  at  time  steps  15,  16,  17,  18,  19,  20,  21  (Day  2),  etc. 

A.2.2  Worksheet  PopulationAreas 

Figure  A. 3  shows  the  worksheet  used  to  specify  information  about  the  location  and  the 
number  of  the  CEPs.  Depending  on  the  affected  nation,  the  Population  Areas  (PAs)  could 
correspond  to  provinces,  regions,  districts,  counties  or  any  subdivisions  relevant  to  the  area. 
The  blue-shaded  cells  represent  values  that  are  auto-generated  by  the  GUI  and  should  not 
be  modified  by  the  user. 

Each  row  is  associated  with  one  PA  and  must  contain  the  information  shown  in  Table  A. 2. 
For  the  example  in  Figure  A. 3,  the  estimated  261  CEPs  located  in  PA02  are  expected  to  go 
by  their  own  means  to  either  AP04,  EC01  or  EC02  in  a  proportion  of  80%,  10%  and  10%, 
respectively.  They  are  expected  to  leave  at  a  rate  of  10%  per  day,  for  10  days  (as  specified 
in  cells  P4:Y4). 
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Version  = 

(change  .f  input  3 
data  is  changed) 


1790  [16,18,19] 


APSum  I  EC  Con 


p|q|  r|s  I  t  I  u  I  V  |  W  |  X  | 

Percentage  of  People  Leaving  per  Day 


Figure  A. 3:  Graphical  user  interface  -  population  areas  worksheet. 


The  information  about  the  PAs  is  not  directly  used  in  the  optimization  process;  it  is  rather 
used  to  approximate  new  CEPs’  arrival  at  the  APs  and  ECs.10 

A.2.3  Worksheet  AssemblyPoints 

The  input  parameters  on  the  APs  are  captured  in  the  worksheet  presented  in  Figure  A. 4. 
In  the  worksheet,  one  row  is  associated  with  a  single  AP.  Similar  information  as  for  the 
PAs  are  required.  In  addition  to  the  identifier  (column  A),  the  name  of  the  AP  (column  B), 
the  latitude  and  longitude  (columns  C  and  D),  and  the  connected  EC* 11  (column  F),  the 
user  must  enter  the  capacity  of  the  APs  (column  E)  and  the  transporter  type  available  to 
move  CEPs  from  the  AP  to  its  connected  EC  (column  I). 

The  cells  in  columns  M  to  V  are  calculated  automatically  inside  the  GUI.  For  example, 
the  estimated  number  of  CEPs  arriving  on  their  own  on  Day  1  at  AP13  (rounded  to  the 
nearest  integer)  is  35  (cell  M15).  It  corresponds  to  the  sum  of  the  number  of  CEPs  coming 
from  PA07  and  from  PA15  on  Day  1.  As  shown  in  cell  H15,  PA07  and  PA15  are  the  only 
population  areas  connected  to  AP13.  Numerically,  it  is  calculated  as  follows: 

<From  PA07>  <From  PAis> 

((0.40x350)  x  0.10)  +  ((0.40x531)  x  0.10)  (A.l) 

14.00  +  21.24  =  35.24 


The  values  in  Equation  A.l  were  taken  from  row  9  (for  PA07)  and  row  17  (for  PA15)  in 
Figure  A. 3. 

10  The  number  of  new  CEPs’  arrival  at  the  ECs  is  also  a  function  of  the  CEPs  who  arrive  via  transporters 
(i.e.  buses).  This  is  accounted  for  in  the  mathematical  formulation  of  the  problem. 

11  It  is  assumed  that  each  AP  is  connected  to  at  most  one  EC. 
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Table  A. 2:  Input  parameters  in  worksheet  P opul at ionAre as. 


Column 

Description 

ID 

A 

Identifier  of  the  PA.  It  must  be  a  numerical  value 
starting  at  1. 

Name 

B 

Name  of  the  PA. 

Lat  and  Lon 

C-D 

Representative  latitude  and  longitude  coordinate 
of  the  PA.  It  could  be  the  geometric  centre  of  the 

area. 

Population 

E 

Estimated  number  of  CEPs  to  be  evacuated  in  the 
PA. 

AP  Connections 

F 

Vector  containing  the  APs  used  by  CEPs  in  the  PA. 

AP  Percentages 

G 

Vector  with  fraction  of  CEPs  going  to  each  AP.  The 
dimension  of  the  vector  should  match  the  vector 

AP  Connections. 

EC  Connections 

F 

Vector  containing  the  ECs  used  by  CEPs  in  the  PA 

EC  Percentages 

G 

Vector  with  fraction  of  CEPs  going  to  each  EC.  The 
dimension  of  the  vector  should  match  the  vector 

EC  Connections. 

Departure  Distribution 

M 

The  type  of  distribution  departure.  The  potential 
values  are:  “1  -  Manual”,  “2  -  Mad  Rush”,  “3  -  Wait 
and  See”  and  “4  -  Orderly”. 

%  of  CEPs  at  the  PA 
leaving  per  day 

P-... 

Expected  percentages  of  CEPs  leaving  on  any  day. 
If  the  Departure  Distribution  is  set  to  “1  -  Man¬ 
ual”,  then  the  percentages  must  be  entered  by  the 
user,  otherwise,  they  are  auto-calculated. 

1 

A 

B 

C 

D 

E 

F 

G 

H 

I 

K 

L 

M 

N 

0 

P 

Q 

R 

S 

T 

U 

V 

nAPs  = 

21 

|m"“ 

50) 

Version  = 

(change  if  input  3 
data  is  changed) 

Estimated  Number  of  People  Arriving  (on  the  own) 
at  Assembly  Points  Centre  per  Day 

2 

ID 

Name 

Lat 

Lon 

Capacity 

EC  Connections  (max  of  1) 

#  of  PA  Connected 

List  of  PAs  Connected 

Transport  Type(s)  to  EC 

Sum 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

3 

1 

AP01 

49.9 

-74.2 

100 

[1] 

1 

[10] 

[1] 

72 

7 

7 

7 

7 

7 

7 

7 

7 

7 

7 

4 

2 

AP02 

49.1 

-66.4 

100 

[2] 

1 

[11] 

[1] 

32 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

5 

3 

AP03 

49.1 

-68.7 

100 

[2] 

1 

[9] 

[1] 

110 

11 

11 

11 

11 

11 

11 

11 

11 

11 

11 

6 

4 

AP04 

48.1 

-72.2 

100 

[1] 

1 

[2] 

[1] 

209 

21 

21 

21 

21 

21 

21 

21 

21 

21 

21 

7 

5 

AP05 

47.8 

-68.5 

100 

[2] 

1 

[1] 

[1] 

152 

15 

15 

15 

15 

15 

15 

15 

15 

15 

15 

8 

6 

AP06 

47.5 

-77.5 

100 

[1] 

1 

[8] 

[1] 

280 

28 

28 

28 

28 

28 

28 

28 

28 

28 

28 

9 

7 

AP07 

47.2 

-73.4 

100 

[1] 

1 

[4] 

[1] 

200 

20 

20 

20 

20 

20 

20 

20 

20 

20 

20 

10 

8 

AP08 

47.0 

-71.9 

100 

12] 

1 

[3] 

[1] 

532 

53 

53 

53 

53 

53 

53 

53 

53 

53 

53 

11 

9 

AP09 

46.4 

-70.3 

100 

[2] 

1 

[12] 

[1] 

71 

7 

7 

7 

7 

7 

7 

7 

7 

7 

7 

12 

10 

AP10 

46.2 

-76.2 

100 

[1] 

1 

[7] 

[1] 

140 

14 

14 

14 

14 

14 

14 

14 

14 

14 

14 

13 

11 

AP11 

45.9 

-73.5 

100 

[1] 

1 

[14] 

[1] 

305 

30 

30 

30 

30 

30 

30 

30 

30 

30 

30 

14 

12 

AP12 

45.9 

-72.3 

100 

[1] 

1 

[17] 

[1] 

178 

18 

18 

18 

18 

18 

18 

18 

18 

18 

18 

15 

13 

AP13 

45.7 

-75.1 

100 

[1] 

2 

[7,15] 

[1] 

352 

35 

35 

35 

35 

35 

35 

35 

35 

35 

35 

16 

14 

AP14 

45.7 

-74.1 

100 

[1] 

1 

[15] 

[1] 

212 

21 

21 

21 

21 

21 

21 

21 

21 

21 

21 

17 

15 

AP15 

45.6 

-71.1 

100 

[2] 

1 

[5] 

[1] 

118 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

18 

16 

AP16 

45.5 

-73.8 

100 

HI 

2 

[6.13] 

[1] 

604 

60 

60 

60 

60 

60 

60 

60 

60 

60 

60 

19 

17 

AP17 

45.4 

-73.2 

100 

[1] 

1 

[16] 

[1] 

342 

34 

34 

34 

34 

34 

34 

34 

34 

34 

34 

20 

18 

AP18 

45.4 

-73.4 

100 

[1] 

2 

[6.16] 

[1] 

790 

79 

79 

79 

79 

79 

79 

79 

79 

79 

79 

21 

19 

AP19 

45.4 

-73.7 

100 

[1] 

2 

[6,13] 

[1] 

604 

60 

60 

60 

60 

60 

60 

60 

60 

60 

60 

22 

20 

AP20 

45.1 

-72.8 

100 

[1] 

1 

[16] 

[1] 

411 

41 

41 

41 

41 

41 

41 

41 

41 

41 

41 

23 

21 

AP21 

45.2 

-72.1 

100 

[1] 

1 

[5] 

[1] 

118 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

Figure  A. 4:  Graphical  user  interface  -  assembly  points  worksheet. 


38 


DRDC-RDDC-2015-R074 


A.2.4  Worksheet  EvacuationCentres 


A  screenshot  of  the  worksheet  EvacuationCentres  is  shown  in  Figure  A. 5.  Each  row  repre¬ 
sents  an  EC.  The  information  required  for  each  EC  includes  the  site  identifier  (column  A), 
the  name  of  the  EC  (column  B),  the  site  coordinates  (columns  C  and  D),  the  capacity  of 
the  EC  (column  E),  the  connected  SH  (column  F)  and  the  transporter  type  (column  I). 

The  values  in  Column  K  represent  the  expected  time  to  process  each  CEP  at  the  EC. 
Specifically,  they  correspond  to  the  delay  between  the  CEP’s  arrival  at  the  EC  and  its 
possible  departure.  The  time  values  are  fixed  for  each  CEP  and  are  expressed  in  terms  of 
minutes.  In  this  example,  the  value  for  each  EC  is  set  to  50  minutes  which  is  less  than  “2 
hours”,  i.e.  the  time  step  considered  in  the  formulation  (see  cell  E2  in  Figure  A. 2),  implying 
that  the  processing  time  would  not  be  modelled.  On  the  other  hand,  if  the  time  step  was 
still  “2  hours”  but  that  the  processing  time  was  240  minutes,  then  a  delay  of  2  time  steps 
(240  minutes  divided  by  120  minutes  per  time  step)  would  be  applied  to  each  CEP  when 
they  arrived  at  the  EC. 

The  number  of  CEPs  arriving  each  day  directly  at  the  EC  without  going  through  an  AP 
(i.e.  the  blue-shaded  cells  on  the  right  in  Figure  A. 5)  is  calculated  in  a  similar  way  as  shown 
in  Equation  A.l. 


Figure  A.  5:  Graphical  user  interface  -  evacuation  centres  worksheet. 

A.2.5  Worksheet  Saf  eHavens 

Figure  A. 6  includes  the  form  with  the  data  on  the  SHs.  For  each  SH,  the  required  information 
consists  of  an  identifier  (column  A),  the  name  (column  B),  the  coordinates  (columns  C  and  D) 
and  the  site  capacity  (column  E).  The  content  of  the  blue-shaded  cells  are  auto-populated 
from  the  information  entered  in  the  Worksheet  EvacuationCentres. 


A 

B 

C 

D 

E 

F 

G 

nSHs  = 

1 

1 

(max  is  10) 

Version  = 

(change  if  input 
data  is  changed) 

3 

2  10 

Name 

Lat 

Lon 

Capacity 

#  of  EC  Connected 

List  of  ECs  Connected 

3  1 

SH01 

45.9 

-77.3 

10000 

2 

[1.2] 

4 

5 

Figure  A. 6:  Graphical  user  interface  -  safe  havens  worksheet. 
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A.2.6  Worksheet  DistMatrix 


The  distances  between  the  various  locations  in  the  evacuation  chain  must  also  be  specified  by 
the  user.  This  is  completed  using  the  form  in  Figure  A. 7.  The  distances  must  be  expressed 
in  kilometers  (km).  A  value  of  -1000  indicates  that  there  is  no  connection  between  the  two 
sites.  For  example,  there  is  no  connection  between  APoi  and  EC02,  and  AP01  and  SHoi-  The 
list  of  locations  on  the  left  in  the  matrix  (cells  C5:C28)  and  at  the  top  (cells  Y4:AA4)  are 
automatically  filled  by  the  GUI  based  on  the  data  provided  in  Worksheets  AssemblyPoints, 
EvacuationCentres  and  SafeHavens.  For  instance,  the  distance  that  the  ferry  has  to  sail 
between  EC02  and  SH01  is  280  km.  The  distances  are  used  to  estimate  the  number  of  trips 
that  a  transporter  can  complete  in  a  given  time  period. 


Compute 

Distances 


Name 

EC01 

EC02 

SHOI 

APOI 

340.0 

-1000.0 

-1000.0 

AP02 

-1000.0 

325.0 

-1000.0 

AP03 

-1000.0 

304.0 

-1000.0 

AP04 

289.0 

-1000.0 

-1000.0 

AP05 

-1000.0 

254.1 

-1000.0 

AP06 

316.0 

-1000.0 

-1000.0 

EC01 

-1000.0 

-1000.0 

180.0 

EC02 

-1000.0 

-1000.0 

280.0 

SHOI 

-1000.0 

-1000.0 

-1000.0 

Figure  A.  7:  Graphical  user  interface  -  distance  matrix  worksheet. 

When  there  is  a  large  number  of  sites  in  the  scenario,  the  button  “Compute  Distances”  at 
the  top  of  the  GUI  can  be  used  to  automatically  calculate  the  distances  between  the  sites. 
Once  clicked,  the  distances  in  the  blue-shaded  cells  are  computed  by  GUI  using  internal 
calls  to  Google  Maps.  This  feature  may  not  be  available  depending  whether  or  not,  Google 
Maps  has  required  data  pertaining  to  the  area  where  the  NEO  is  conducted. 

A.2.7  Worksheet  TransportTypes 

The  data  on  the  transporter  types  considered  in  the  scenario  are  specified  via  the  form 
presented  in  Figure  A. 8.  The  list  of  parameters  that  must  be  specified  are  described  in 
Table  A. 3. 
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A 

B 

C 

D 

E 

F 

G 

H 

1 

J 

K 

nTTs  = 

1 

2 

(max  is  20) 

ID 

2 

Name 

Description 

Number 

Available 

Capacity 

Speed  (km/h) 

Operates  from 
(timestep) 

Operates  until 
(timestep) 

Utilization 

Threshold 

Min  Max 

TT  can  be  used  at 

1 

3 

Bus 

Mini-van  type  1  used  between 
AP  and  EC 

13 

40 

75 

4 

10 

50% 

100% 

AP[1,2,3,4,5,6,7,8,9,10,11,12,13, 
14,15,16,17,18,19,20,21]  -  EC[] 

2 

4 

Ferry 

Ferry  EC  to  SH 

5 

200 

25 

1 

24 

50% 

100% 

AP[]  -  EC[1,2] 

5 

Figure  A. 8:  Graphical  user  interface  -  types  of  transporters  worksheet. 


Table  A. 3:  Input  parameters  in  worksheet  TransportTypes. 


Column 

Description 

ID 

A 

Identifier  of  the  transporter.  It  must  be  a  numerical 
value  starting  at  1. 

Name 

B 

Name  of  the  transporter. 

Description 

C 

A  description  of  the  asset. 

Number  Available 

D 

Total  number  of  assets  available  per  time  step. 

Capacity 

E 

Maximum  number  of  CEPs  for  one  trip. 

Speed 

F 

Speed  of  the  transporter  (expressed  in  km/h). 

Operates  from  (time  step) 

G 

Time  steps  between  which  the  transporter 

Operates  for  (time  step) 

H 

is  available  during  each  day. 

Min/Max  Utilization 

I-J 

Minimum  and  maximum  £11  of  a  transporter’s  ca¬ 
pacity. 

The  “Speed”  (column  F)  and  the  “Time  Step”  (cell  E2  in  Figure  A. 2)  values  are  used  in 
conjunction  with  the  distances  provided  in  Figure  A. 7  to  estimate  the  maximum  number  of 
trips  that  a  transport  asset  can  do  in  one  time  step.  To  illustrate  how  this  is  calculated,  we 
consider  the  following  example: 

•  A  bus  is  used  to  move  CEPs  between  AP^  and  EC b  ; 

•  Distance  between  AP^  and  EC#  is  100  km; 

•  Speed  of  the  bus  is  75  km/h;  and 

•  Time  period  considered  in  the  model  is  6  hours. 


Based  on  this  information,  the  maximum  number  of  trips  that  the  bus  can  complete  between 
APa  and  EC#  in  one  time  period  is  2,  and  is  calculated  as  follows: 


6  hours 

2  x  ( TTkm/E  T  0. 125  hours) 


[2.057J  =  2  trips. 


(A.2) 


In  Equation  A.2,  the  denominator  corresponds  to  the  total  time  needed  to  complete  a 
roundtrip  between  AP^  and  EC b-  The  0.125  hour  represents  the  time  delay  allotted  at 
each  site  in  between  the  arrival  and  the  next  departure.  This  value  is  currently  set  to  0.125 
hour  but  can  be  easily  changed. 
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A.2.8  Worksheet  FixedTransport 


There  are  NEO  scenarios  where  part  of  the  transportation  schedule  may  be  set  in  advance. 
For  example,  it  is  possible  that  another  nation  has  a  bus  running  a  trip  every  morning 
between  two  sites  with  empty  seats  made  available  to  Canadians.  Such  information  should 
be  considered  in  the  optimization  process.  This  is  done  in  the  Worksheet  FixedTransport 
shown  in  Figure  A. 9.  The  user  must  specify  the  departure  site  (column  B),  the  destination 
site  (column  C),  type  of  transporter  used  to  move  the  CEPs  (column  D),  the  time  period 
(column  E)  and  the  number  of  trips  (column  F).  For  example,  the  first  record  in  Figure  A. 9 
indicates  that  the  solution  produced  by  the  optimization  process  should  include  one  bus 
trip  between  APqi  and  ECoi  on  the  time  period  2. 


A 

B 

C 

D 

E 

F 

nTripsFixed  = 

2 

(max  is  1000) 

Used  as  contraints  in  the  optimization 

1 

ID 

2 

From 

(e.g.,  AP01) 

To 

(e.g.,  EC01) 

TT 

TimeStep 

Nbr  of 

Trips 

3  1 

AP01 

EC01 

Bus 

2 

1 

4  2 

AP02 

EC02 

Bus 

2 

1 

5 

6 

Figure  A.  9:  Graphical  user  interface  -  fixed  transport  worksheet. 

A.3  Format  of  the  input  data  files 

The  format  of  the  ten  “dat”  input  files  are  presented  in  Figure  A. 10  and  consists  of  semi-colon 
separated  files: 

1.  AssemblyPoints.dat:  a  list  of  the  assembly  points  (names); 

2.  EvacuationCentres.dat:  a  list  of  the  evacuation  centres  and  their  processing  times; 

3.  SafeHaven.dat:  a  list  of  the  safe  havens; 

4.  Arrival.dat:  lists  the  location,  time,  and  number  of  CEPs  arriving  at  that  time 
period; 

5.  TransporterTypes.dat:  lists  the  transporter  name,  quantity,  capacity,  operates  from 
and  operates  to; 

6.  TransportArcs.dat:  lists  the  source  location,  destinations,  transporter  type,  maxi¬ 
mum  number  of  trips  in  the  time  step,  minimum  and  maximum  utilization; 

7.  Timelnterval.dat:  lists  the  number  of  time  periods  to  be  modelled,  and  also  the 
desired  maximum  number  of  time  periods  to  complete  the  NEO; 

8.  SiteCapacities.dat:  lists  location  names  and  capacity  (number  of  CEPs)  of  each 
location; 

9.  FixedTimeTransportArcs.dat:  lists  the  source  and  destination  locations,  transporter 
type  and  time  for  a  mandatory  trip;  and 
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10.  BlackOut.dat:  lists  the  set  of  time  periods  when  no  new  movement  of  CEPs  via 
transporters  is  permissible. 

A.4  Processing  of  output  data 

There  is  a  large  amount  of  data  generated  once  the  optimal  (or  near  optimal)  solution 
has  been  found  by  SCIP-SoPLEX  integer  program  solver.  The  output  data  is  written  to 
a  hie  called  ScipOutput.dat  that  is  automatically  saved  in  the  directory  DataFiles.  To 
generate  and  parse  solution  output,  the  batch  file  (ProcessScipBatch.bat)  parses  the  raw 
SCIP-SoPLEX  output  (ScipOutput.dat)  and  creates  four  tab-separated  files: 

1.  OptTransport.dat:  lists  the  source  location  (e.g.  AP),  destination  location  (e.g.  EC), 
transporter  type,  time,  and  number  of  transporter  departures  of  the  respective  type 
departing  the  source  to  destination  at  the  specified  time; 

2.  OptTrips.dat:  lists  the  source  location,  destination  location,  transporter  type,  time, 
and  number  of  trips  taken  by  the  transporters  during  the  time  period; 

3.  OptUsage.dat:  lists  the  source  location,  destination  location,  transporter  type,  time, 
and  number  of  transporters  used  during  specified  time  period; 

4.  0ptIP.dat:  lists  the  location,  time,  and  number  of  people  at  the  location  at  that  time; 
and 

5.  OptTravelling.dat:  lists  the  source  location,  destination  location,  transporter  type, 
time,  and  number  of  people  travelling  via  the  transporter  type  during  the  specified 
time  period. 

The  tab-separated  files  are  then  read  by  the  Microsoft  Excel  macros  or  Matlab  scripts  to 
generate  meaningful  graphs  and  tables.  For  example,  the  authors  created  Matlab  scripts  to 
show  the  expected  number  of  CEPs  as  a  function  of  time  at  specific  location  (see  Figure  8 
in  Section  4)  and  the  number  of  assets  and  trips  required  per  transporter  type  as  a  function 
of  time  (see  Figure  9  in  Section  4).  The  Matlab  scripts  are  not  included  neither  are  they 
explicitly  discussed  in  this  annex,  but  they  can  be  made  available  to  the  user. 
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A.5  ProcessScipBatch 


- 

P 

cd 

P 

X 

= 

bO 

p 

P 

0 

B 

P 

■H 

o 

Ph 

p 

rH 

CO 

CO 

X 

P 

q 

Ph 

> 

ro 

■H 

Ph 

cd 

b 

P 

1— 1 

B 

H 

H 

=  P 

H 

P 

P 

P  Ph 

P 

= 

Ph 

= 

Ph 

X  o 

= 

Ph 

C_) 

LJ 

CJ 

X 

•  p 

X 

p 

1  p 

P 

P 

Ph  rH 

P 

P 

’  1 — 1 

i — 1 

B  -H 

Ph  -H 

Ph 

■rH 

P  Uh 

Ph 

•H 

b 

1  Ph 

S 

Uh 

H  1 

s 

Uh 

© 

1 

(1) 

P 

Cl) 

1 

H 

'  P 

H 

P 

P  0 

H 

P 

0 

0 

rH  O 

<u 

<  a 

P 

o 

•rH 

P 

o 

rH 

i 

rH 

Uh  - 

rH 

i  — 

— 

— 

Uh 

Uh 

P  ~ 

Uh 

1 

*» 

1 

0 

| 

•> 

□  ~ 

P 

i  »> 

0 

0 

** 

CJ 

i 

C_) 

-  - 

CJ 

.  ~ 

— 

rS 

— 

- 

-  / 

r*- 

>  ^ 

rS 

Ph  O 

rS 

o 

o 

M  •• 

o 

N  •• 

J* 

1  •!—> 

X 

1  T-) 

1 

•1—) 

p  p 

1 

•I-) 

P 

1  P 

P 

p 

-  o 

p 

p 

o 

o 

o 

p  x' 

v-/ 

Pi 

P 

/ 

U  - 

p 

/ 

U  - 

u 

P 

u 

P 

p 

P  P 

p 

P  P 

p 

p 

B  o 

cd 

P 

6 

i  o 

S 

u 

p  P 

B 

U 

P 

1  cd 

p 

p 

O  rH 

p 

P 

c 

o 

1 — 1 

0  Ph 

o 

c 

I  Ph 

0 

Ph 

1  P 

0 

Ph 

1 

P 

1 

p 

B 

P 

P 

p 

B 

1  1 

1 

09 

1 

1 

09 

-69- 

09 

X 

X 

X 

0  « 

X 

S 

1  ~ 

s 

** 

P 

1 

§ 

1 

1 

1 

9* 

Ph  ^ 

N  -X* 

5 

/ 

1 — 1  ~ 

X 

/ 

•  • 

P 

£ 

P 

!  © 

p 

P 

P  u 

p 

P 

U  U 

U 

U 

U  P 

u 

U 

P 

1  P 

P 

p 

P  rH 

p 

P 

CD 

P 

cd 

6 

1  Ph 

s 

Ph 

S  © 

S 

Ph 

r-Q 

P 

1 

P 

1  B 

P 

TJ 

1  1 

1 

I 

1 

1 

CD 

09 

09 

09  - 

09 

H-^ 

X 

X 

** 

X  - 

X 

P 

q 

— 

q 

1 

P 

p 

w 

CD 

** 

1 

1  09 

09 

09 

o 

'  / 

o 

/ 

O  - 

o 

/ 

Jh 

p 

B 

B 

p 

p 

P  P 

P 

■p 

c 

1  P 

0 

P 

0  U 

0 

P 

c 

i  U 

o 

U 

O  P 

O 

U 

U  P 

u 

P 

U  rH 

o 

P 

£<9-  rH 

-69- 

09  P, 

09 

Ph 

Ph 

P 

Ph 

P 

P 

P 

P 

P  B 

P 

P 

u  b 

U 

P 

U  1 

o 

B 

U 

p 

1 

P 

P 

p 

1 

P 

: 

P 

p  ~ 

cd 

oj 

b 

1  ~ 

B 

S  - 

S 

m 

&, 

■99-  - 

09 

„  * 

09^09 

09 

-60 

09 

09 

u 

S- 

'  X 

Sr* 

/ 

S-*  Ph 

S-* 

X 

N 

is 

1— 1 

X 

C- 

.  - 

O- 

0--  - 

■  P 

_ 

P 

—  P 

— 

P 

a 

u 

U 

U 

cd 

p 

P 

P 

u 

o 

P 

’  Ph 

P 

Ph 

P  Ph 

p 

Ph 

P  CD 

P 

P 

P  P 

cd 

P 

X  B 

X 

P 

X  B 

X 

B 

1 

P 

p 

P 

P 

1  /*  \ 

CD 

Ph  P 

Ph 

P 

Ph  P 

Ph 

P 

,  * 

X 

P  X 

X 

q=i 

P 

1  P 

P 

P 

0  P 

0 

P 

a 

1 

a 

o  • 

o 

-p 

Ph  Pi 

Ph 

Ph 

Ph  Ph 

Ph 

& 

P 

•H 

1  S 

•H 

B 

•h  & 

•rH 

B 

X 

U  P 

U 

0) 

O  P 

o 

P 

CO 

CO  H 

C/J 

H 

CO  H 

C/J 

H 

X 

U  U 

u 

U 

U  U 

o 

U 

q 

bO  bO 

bo 

bO 

bO  bO 

bo 

bO 

CD 

(0 

' 

s— ' 

' — ^ 

s— ' 

1 

o 

X 

!  X 

X 

X 

X  X 

X 

X 

o 

q 

I  S 

q 

q 

q  B 

q 

q 

o 

•H 

1  B 

s 

u 

i  B 

B 

CO 

c 

i  o 

o 

o 

o  o 

o 

o 

CJ 

•  o 

o 

o 

o  o 

o 

o 

43 

1 

1 

1 

1  1 

i 

CD 

1 

X 

X 

X 

1 — 1 

1  rH 

1 — 1 

i — 1  rH 

1 — 1 

<u 

i  P 

Ph 

p 

p 

Ph 

P  P 

Ph 

p 

p 

CJ 

CM 

p 

1  P 

fed 

p 

p 

fed 

P  P 

B 

p 

r0 

O 

C/J 

1  CO 

Cl) 

CO 

co 

a; 

CO  CO 

p 

CO 

m 

00 

b 

!  P 

H 

p 

p 

H 

B  B 

H 

B 

B 

& 

p 

i  P 

p 

p 

P  P 

P 

P 

■H 

is 

:  IS 

i — 1 

IS 

is 

rH 

13  IS 

i — 1 

15 

is 

U 

c 

O 

P 

o 

o 

P 

o  o 

P 

o 

o 

H 

CO 

Ph  Ph  X 

Ph 

Ph 

X 

Ph  Ph  X 

Ph 

Ph 

DRDC-RDDC-2015-R074 


This  page  intentionally  left  blank. 


46 


DRDC-RDDC-2015-R074 


Annex  B:  Mixed  integer  linear  program  formulation 


This  section  presents  mathematical  details  of  the  mixed  integer  linear  program  formulation 
for  STONE(Opt).  The  model  is  further  elaborated  in  external  literature  [23]. 

B.1  Sets  and  input  parameters 

B.1.1  Time  period,  sites,  and  CEP  arrival 

Define  nPeriods  be  the  total  number  of  time  periods  to  be  considered.  A  single  time  period 
can  be  interpreted  as  an  hour,  a  few  hours,  a  half-day,  day,  etc.  Let  T  =  {1 ,...,  nPeriods} 
be  the  set  of  time  periods.  Let  lastPeriod  be  an  input  parameter  less  than  or  equal  to 
nPeriods  indicating  the  last  time  period  by  which  all  CEPs  have  been  evacuated  to  safe 
havens. 

Let  AP  be  the  set  of  assembly  points,  EC  the  set  of  evacuation  centres,  SPl  the  set  of  safe 
havens,  and  define  Sites  =  APL)  EC  L)  SPt  to  be  the  set  of  all  sites  being  considered.  Define 
a  set  SitesTimes  =  Sites  x  T  with  indices  {i,t}.  Define  SiteC apacitm  to  be  the  capacity 
(number  of  people)  of  site  i  €  Sites ,  and  ProcessTimei  to  be  the  processing  time  of  an 
individual  at  evacuation  centres  i  €  EC. 

Let  Arrivalj.j  be  the  input  parameter  indicating  the  number  of  CEPs  from  population  areas 
expected  to  arrive  at  site  i  €  APUEC  at  time  period  t  E  T.  Define  total  Population  as  the 
sum  of  all  Arrivalif, :  total  Population  =  Arrival^- 

{i,t}£APuECxT 

B.1 .2  Transporters  and  transport  arcs 

Let  M  be  the  set  of  transporter  types  and  define  TransC apacitym  to  be  the  capacity 
(number  of  CEPs)  of  transporter  type  m  E  M  and  TransQtym  to  be  the  total  number  of 
transporters  of  type  m  E  M  available. 

Define  Transport  Arcs  to  be  the  set  of  triples  {i,j,m}  of  feasible  network  arcs  indicating 
which  transport  types  m  E  M  can  travel  from  site  i  to  j  with  i,j  E  Sites. 

Let  Transport  ArcsTripsij^m  with  {i,j,m}  €  Transport  Arcs  be  the  maximum  number  of 
trips  that  a  single  transporter  of  type  m  can  accomplish  in  a  single  time  period  between 
sites  i  and  j.  A  fractional  value  of  TransportArcsTripsij)7n  is  permitted  and  indicates  that 
a  single  trip  spans  more  than  one  time  period  (i.e.  the  trip  spans  TransportAlcsTrips .  m  time 
periods). 

B.1. 3  Optional  inputs 

Define  TransportArcsMinUseij)Tn  with  {i,j,m}  £  TransportArcs  to  be  the  minimum 
percent  of  transporter  type  m’s  capacity  to  which  the  transporter  needs  to  be  filled  to 
consider  a  trip  between  sites  i  and  j. 
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Similarly,  define  Transport  ArcsM  axU seij)in  with  {i,j,m}  G  Transport  Arcs  to  be  the 
maximum  percent  of  transporter  type  m’s  capacity  to  which  the  transporter  may  be  filled 
to  consider  a  trip  between  sites  i  and  j. 

Let  FixedTransportTimesij^mj ,  with  G  Transport  Arcs  and  t€.T,  prescribe  the 

exact  number  of  trips  required  by  transporter  type  m  at  time  period  t  from  site  i  to  j. 

B.2  Decision  variables 

•  Define  Xij,mj,  to  be  a  nonnegative  variable  indicating  the  number  of  people  that 
departed  from  site  i  to  site  j  during  time  period  t  on  transporter  type  rn  ({ i,j,m }  € 
Transport  Arcs) .  By  design,  Xij^t  s  are  allowed  to  take  fractional  values  as  the  output 
of  interest  of  the  optimization  model  is  not  how  many  CEPs  travel  on  any  particular 
transporter,  but  rather  the  assignment  and  usage  of  transporters  and  feasibility  of 
sites  (with  respect  to  capacity).  The  Xij,rnx's  can  be  constrained  to  be  integers,  at  the 
expense  of  computational  time. 

•  Let  Zi.j.m.t  be  an  integer  variable  specifying  the  number  of  transporters  of  type  m 

departing  site  i  to  site  j  during  time  period  t  with  G  Transport  Arcs. 

•  Variable  Vn.j.m.t  is  defined  as  an  integer  variable  specifying  the  number  of  transporters 

of  type  m  being  used  on  arc  {i,j}  during  time  period  t.  When  transporters  can 
complete  a  trip  within  a  time  period,  then  corresponding  variables  are  equal  to 

their  counterparts  • 

•  Let  Wi,j,m  t  be  an  integer  variable  specifying  the  number  of  trips  that  transporters  of 

type  m  commence  on  arc  {i,j}  during  time  period  t  with  G  Transport  Arcs. 

•  Define  IP^t  be  the  number  of  people  located  at  site  i  G  Sites  and  time  t  G  T,  and  let 
ipix  be  the  number  of  people  located  at  an  evacuation  centre  {i  G  EC)  at  time  t  who 
have  been  processed  and  are  waiting  to  travel  further. 

•  Let  Pr  be  the  number  of  people  located  at  an  evacuation  centre  (i  G  EC)  who  are 
being  processed  during  time  t. 

•  Define  with  {i,f}  G  SiteTimes  to  be  the  number  of  people  departing  site  i  during 
time  period  t. 

•  Define  At,t  with  {z,f}  €  SiteTimes  to  be  the  number  of  people  arriving  at  site  i  during 
time  period  t. 

•  Define  1)  for  each  t  G  T  to  be  a  binary  variable  indicating  whether  the  evacuation  of 
affected  individuals  from  the  danger  area  is  complete  ( Yt  =  0)  or  not  (Yt  =  1). 

•  Define  o^t  with  {z,t}  G  SiteTimes  be  a  multiplier  greater  than  or  equal  to  one  indicating 
the  degree  to  which  site  V s  capacity  is  exceeded  at  time  t. 
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B.3  Constraints 


B.3.1  NEO  end  time  and  limiting  the  number  of  days  to  evacuate  from  area  of 
danger 

Recall  that  Yt  for  t  E  T  is  a  variable  that  indicates  whether  the  evacuation  of  CEPs  from 
the  danger  area  is  complete  (Y)=0),  and  input  parameter  lastPeriod  specifies  the  last  time 
period  by  which  all  CEPs  have  been  evacuated  to  safe  havens.  The  constraint 

YlastPeriod - 0  (B.l) 

forces  Yiastperiod  to  be  set  to  zero  (indicating  the  evacuation  is  complete)  at  the  specified 
time  period.  Constraints  (B.2)  relate  the  arrival  of  all  CEPs  at  an  SH  to  the  evacuation 
completion  variables: 

for  all  t  E  T  :  total  Population  —  E  IP>.  t<Yp  total  Population  (B.2) 

s£SH 

A  constraint  is  needed  to  ensure  that  if  Yt  is  set  to  zero,  then  all  subsequent  time  periods, 
t+  l,t  +  2,  ...,nPeriods  are  also  set  to  zero: 

for  all  f  >  1  :  V-i  >  Yt.  (B.3) 

B.3. 2  Site  accounting  constraints 

Variables  IPt.t  indicate  the  number  of  CEPs  at  site  i  at  time  t.  The  constraints 

for  all  {i,t}  e(APU  SH)  x  Times  : 

if  f  >  1  :  IPi,t  ==  IPi,t- 1  +  A,t  ~  A,t  +  Arrival i>t,  (B.4) 

else  :  I Piti==  Ai^  — Diti  + Arrival^,  (B.5) 

ensure  proper  accounting  of  CEPs  arriving  and  departing  sites  at  each  time  period. 

Equivalent  constraints  for  evacuation  centre  sites  are  listed  below  and  include  processing 
periods: 

for  all  {i,t}  E  EC  x  Times  : 

t 

IPi,t==iPi,t+  (AijS  + Arrival^) ,  (B.6) 

s=min(  (t— Pr  ocessTimei + 1)  ,t ) 
with  s>0 

if  t  >  1  :  ipiit  ==  ipi,t- 1  -  A,t  +  P'f’i.t,  (B.7) 

else  :  iph\  ==  Pri) x  -  A, i-  (B.8) 

Recall  that  ip%.t  represents  the  number  of  CEPs  at  an  EC  that  have  been  processed  and  are 
waiting  to  travel  further.  Constraint  B.6  determines  the  total  number  of  CEPs  at  an  EC  by 
summing  the  CEPs  that  have  arrived  and  are  being  processed  with  the  CEPs  processed  and 
waiting  to  travel  further. 
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B.3.3  Site  capacity  constraints 


Sites  may  have  a  limit  to  the  number  of  CEPs  that  can  be  processed  or  accommodated 
within  a  particular  time  period.  The  constraint 

for  all  {i,t}  €SitesTimes  : 

IPi,t  <  SiteC apacityt  ■  Oij  (B.9) 

determines  to  what  extent  a  site’s  capacity  is  violated  at  a  particular  time  period — variable 
Oij  represents  the  percentage  of  over  capacity. 


B.3.4  Transportation  arc  flow  constraints 

The  following  constraints  ensure  proper  accounting  of  the  arrival  and  departure  by  linking 
the  variable  representing  the  number  of  CEPs  arriving/departing  to  the  number  of  CEPs 
travelling  via  transporters  from  site  to  site  at  a  particular  time  period: 


for  all  {i,t}  €  SitesTimes  : 

Di,t -  ^  '  xi,j,m,ti 

{i,j,m}  (^Transport  Arcs 

E 

{j  ,i,m}£TransportArcs 


A-ij - 


X 


max(l t  'prarLSp0rtArCSTripSj  i 


with  t> 


max(l,  TrarlSp0rtArcSTripSj  ^ 


(B.10) 

(B.ll) 


Equation  B.ll  sums  the  number  of  CEPs  that  are  arriving  over  all  arcs  leading  to  site  i. 
When  the  transport  time  for  an  transport  arc  exceeds  one  time  period,  the  equation  looks 
back  sufficient  time  period  steps  to  properly  account  for  arrivals. 


B.3.5  Link  travel  of  CEPs  to  transporter  trips 

Constraints  are  defined  to  link  variables  xt,j,mj,  indicating  the  number  of  CEPs  departing 
from  site  i  to  site  j  on  transporter  type  rn  and  time  t,  to  variables  and  'Wijtm,t. 

representing  the  number  of  transporters  initiating  travel  along  that  arc  and  the  number  of 
trips  commencing  during  time  period  t ,  respectively: 

for  all  {i,j,m,t}  £  TransportArcs  x  T  : 

Wi.j.m.t  <nrax(l,  [Transport ArcTripsijt7n\)  ■  z^^t, 

xi,j,m,t  <TransportArcTripsMaxUseij^m  ■  TransportC opacity m  ■  Witjyinj, 
xi,j,m,t  >TransportArcTripsMinUseijtm  ■  TransportC apacitym  ■  Wijtrnj, 

xi,j,m,t 

PZijtTnj. 

Together,  constraints  B.12  and  B.13  ensures  that  the  the  number  of  trips  and  transporters 
conforms  to  transporter  capacity  and  usage  upperbounds  while  being  sufficient  to  transport 


(B.12) 

(B.13) 

(B.14) 

(B.15) 

(B.16) 
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the  number  of  CEPs  represented  by  x*  •  Constraint  B.14  ensures  that  the  number  of 
trips  takes  into  consideration  the  transporter’s  minimum  utilization  factor. 

Constraints  B.15  and  B.16  constrain  the  number  of  transport  assets  departing  on  an  arc  at 
a  particular  time  to  be  less  than  or  equal  to  both  the  number  of  CEPs  departing  and  also 
the  number  of  trips  of  that  commence. 

Further  to  the  constraints  above,  variables  Uijjrri}t,  representing  the  number  of  transporters 
of  type  m  in  use  on  arc  {«,  j},  are  linked  to  the  number  of  transporters  initiating  travel 
along  that  arc,  represented  by  variables  ZijtTn,t,  taking  into  account  the  length  of  such  trips: 

for  all  {i,j,  m,t}  €  Transport  Arcs  x  T  : 
if  TransportArcsTripsij^m  <  1 

then  j, -  'y  '  Zi,j,m,si  (E.17) 

with  +  1  Transport ArcsTrips^  j  m 

else  - •  (B.18) 

B.3.6  Constrain  the  number  of  transporters 

The  number  of  transporters  of  a  specific  type  being  used  anywhere  in  the  network  at  any 
given  time  period  must  respect  the  upperbound  on  the  total  number  of  transporters  available: 

for  all  {m,  i}£tfxT  : 

^2  Ui,j,m,t<TransQtym.  (B.19) 

{i  J  ,m}  ^Transport  Arcs 

B.3.7  Force  the  number  of  trips  for  a  transporter  on  a  particular  route  and  time 

An  optional  constraint  is  to  define  the  exact  number  of  trips  desired  for  a  particular 
transportation  arc  and  a  particular  time.  This  removes  the  variability  for  that  specific  arc 
and  time: 

for  all  {i,j,m,t}  €  Transport  Arcs  x  T  : 
if  FixedTransportTimesitjtm,t  >  0 

then  ==  FixedTransportTimesij>rnj ■  (B.20) 

B.3.8  Site  blackout  periods 

An  optional  constraint  is  to  indicate  time  periods  where  specific  sites  can  neither  accept 
new  CEP  arrivals  nor  have  CEPs  depart.  These  constraints  have  no  effect  on  the  number  of 
CEPs  at  that  site  at  that  time,  only  arriving  and  departing  CEPs: 

for  all  {i,t}  G  Sites  x  B  : 

if  t  >  0  then  Aij  ==  0,  (B.21) 

A,t==  0.  (B.22) 
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B.4  Objective  functions 

Several  objective  functions  are  possible  and  are  defined  in  the  following. 


B.4.1  Minimize  the  total  number  of  NEO  days 

The  objective  is  to  complete  the  NEO  as  quickly  as  possible: 

minimize  Ey*-  (B-23) 

ter 

B.4.2  Minimize  the  average  time  people  spend  in  the  area  of  danger 

Recall  that  IP^t  with  i  €  SH  represents  the  amount  of  people  who  have  arrived  at  a  safe 
haven  by  time  t.  The  objective  is  to  process  and  move  the  most  people  as  possible  and  as 
soon  as  possible  to  a  safe  haven: 

minimize  E  "I  (B.24) 

{i,t}£SHxT 

B.4.3  Minimize  the  amount  of  site  over-capacity 

Recall  that  Oi.t  with  {i,t}  €  SiteTimes  is  a  multiplier  greater  than  or  equal  to  one  indicating 
the  degree  to  which  site  V s  capacity  is  exceeded  at  time  t.  (o^t  —  1)  •  SiteCapacityi  is  the 
number  of  person  time  periods  (e.g.  person  days)  of  site  capacity  overflow.  The  objective  is 
to  minimize  the  number  of  person  time  periods: 

minimize  E  (o^j  — 1)  •  SiteCapacityi.  (B.25) 

{i,t)&SitesTimes 
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Annex  C:  Zimpl  formulation  file 


#  Zimpl  ILP  formulation  file 

#  Created  by  CJOC  OR&A:  Jean-Denis  Caron  and  Bohdan  Kaluzny 

#  Version  date:  5  April  2015 

#  - 

#  INPUT  and  SETS  and  PARAMETERS 

#  - 

param  SelectObj  :=  read  "SelectObj.dat"  as  "In"  ; 
set  Three  : =  {  1  . .  3  } ; 

param  Time [Three]  :=  read  "Timelnterval.dat"  as  "In"  ; 

param  lastTime  :=  Time[l]; 

set  T  :=  {1  ..  lastTime}; 

set  B  :=  {read  "Blackout.dat"  as  "<n+>"}; 

set  AP:={read  "AssemblyPoints.dat"  as  "<ls>"}; 
set  EC:={read  "EvacuationCentres.dat"  as  "<ls>"}; 
set  SH:={read  "SafeHavens.dat"  as  "<ls>"}; 
set  Sites :=AP+EC+SH; 

param  SiteCapacity [Sites]  :=  read  "SiteCapacities.dat"  as  "<ls>2n"; 
param  ProcessTime [EC]  :=  read  "EvacuationCentres.dat"  as  "<ls>2n"; 

set  M:={read  "TransporterTypes.dat"  as  "<ls>"}; 

param  TransCapacity [M]  :=  read  "TransporterTypes.dat"  as  "<ls>3n"; 
param  TransQty[M]  :=  read  "TransporterTypes.dat"  as  "<ls>2n"; 
param  TransStart [M]  :=  read  "TransporterTypes.dat"  as  "<ls>4n"; 
param  TransEnd[M]  :=  read  "TransporterTypes.dat"  as  "<ls>5n"; 

param  Arrival [Sites*T]  :=  read  "Arrival.dat"  as  "<ls,2n>3n"  default  0; 
param  fixy  :=  Time [2]; 


set  TransportArcs : ={read  "TransportArcs.dat"  as  "<ls , 2s , 3s>"} ; 
param  TransportArcsTrips [TransportArcs] 

:=  read  "TransportArcs.dat"  as  "<ls , 2s , 3s>4n" ; 
param  TransportArcsMinUse [TransportArcs]  :=  read  "TransportArcs.dat"  as  "<ls , 2s , 3s>5n" ; 
param  TransportArcsMaxUse [TransportArcs]  :=  read  "TransportArcs.dat"  as  "<ls , 2s , 3s>6n" ; 
param  FixedTransportTimes [TransportArcs*T]  :=  read  "FixedTimeTransportArcs.dat"  as 

"<ls,2s,3s,4n>5n"  default  -1; 

param  totalPopulation : =  sum  <a,t>  in  Sites*T  :  Arrival [a, t] ; 
set  SitesTimes:=  Sites*T; 

# - 

#  VARIABLES 

#  - 

var  z[<i,j,m,t>  in  TransportArcs*T]  integer; 

var  w[<i,j,m,t>  in  TransportArcs*T]  integer; 
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var  u[<i,j,m,t>  in  TransportArcs*T]  integer; 
var  IP [SitesTimes  ]  real  >=  0; 

var  ip [EOT  ]  real  >=  0;  #number  at  EC  that  have  been  processed  and  ready  to  move 

var  Pr[EC*T]  real  >=  0;  #number  processed  at  site  i  at  time  t 

var  A [SitesTimes  ]  real  >=  0; 

var  D [SitesTimes  ]  real  >=  0; 

var  Y[T]  binary; 

var  x[<i,j,m,t>  in  TransportArcs*T]  real  >=  0; 
var  o[Sites*T]  real  >=  1; 
var  Over  real ; 
var  AvgTime  real; 


minimize  SelectedObjective : 

if  SelectObj  ==  1  then  sum  <t>  in  T:  Y[t] 

else  if  SelectObj  ==  2  then  sum  <i,t>  in  SH*T  :  -l*t*IP[i,t] 

else  if  SelectObj  ==  3  then  Over 

else  if  SelectObj  ==  4  then  sum  <i,j,m,t>  in  TransportArcs*T:  z[i,j,m,t] 

else  sum  <i,j,m,t>  in  TransportArcs*T:  w[i,j,m,t] 
end  end  end  end; 


#minimize 

#minimize 

#minimize 

#minimize 

#minimize 


LastTime:  sum  <t>  in  T:  Y[t]; 

AvgTimelnverse :  sum  <i,t>  in  SH*T  :  -l*t*IP  [i ,t] ; 

OverFlow:  Over; 

Transporters:  sum  <i,j,m,t>  in  TransportArcs*T:  z[i,j,m,t]; 
TotalTrips:  sum  <i,j,m,t>  in  TransportArcs*T:  w[i,j,m,t]; 


############################################################################# 
#  Limit  on  number  of  days  for  operation 
############################################################################# 


subto  FixY:  Y[fixy]  ==  0; 

############################################################################# 
#  Used  when  granularity  is  to  the  hour  level 
############################################################################# 


subto  EndTime:  forall  <t>  in  T  do 

totalPopulation  -  sum  <i>  in  SH:  IP[i,t]  <=  Y[t] *totalPopulation; 
subto  EndTimeY:  forall  <t>  in  T  with  (t  >  1)  do  Y[t-1]  >=  Y[t]; 


subto  Demand:  forall  <i,t>  in  SitesTimes\EC*T  do 

if  (t  >  1)  then  IP[i,t]  ==  IP[i,t-l]  +  A[i,t]  -  D[i,t]  +  Arrival[i,t] 

else  IP[i,t]  ==  A[i,t]  -  D[i,t]  +  Arrival[i,t] 

end; 

############################################################################# 

#  Used  when  granularity  is  to  the  hour  level 
############################################################################# 
subto  Processed:  forall  <i,t>  in  EC*T  do 
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if  (t-ProcessTime [i]  >=  1) 

then  Pr[i,t]  ==  A [i , t-ProcessTime [i] ] +Arrival [i , t-ProcessTime [i] ] 

else  Pr[i,t]  ==  0 

end; 

subto  PrAccount:  forall  <i,t>  in  EC*T  do 

IP[i,t]  ==  ip[i,t]  +  sum  <s>  in  {min( (t-ProcessTime [i] +1) ,t)  ..  t} 

with  s  >  0  :  (A[i,s]  +  Arrival  [i , s] ) ; 

subto  DemandEC:  forall  <i,t>  in  EOT  do 

if  (t  >  1)  then  ip[i,t]  ==  ip[i,t-l]  -  D[i,t]  +  Pr[i,t] 

else  ip[i,t]  ==  Pr[i,t]  -  D[i,t] 

end; 

############################################################################# 

#  Site  Capacity 

############################################################################# 
subto  SiteCapacity :  forall  <i,t>  in  SitesTimes  do  IP[i,t]  <=  SiteCapacity  [i] *o  [i ,t] 
subto  SiteOverFlow:  Over  ==  sum  <i,t>  in  SitesTimes  :  (o [i , t] -1) *SiteCapacity [i] ; 

############################################################################# 

#  Departure  and  Arrival  via  transport  arcs 
############################################################################# 


subto  DepartSite:  forall  <i,t>  in  SitesTimes  do 

D[i,t]  ==  sum  <i,j,m>  in  TransportArcs  :  x[i,j,m,t]; 


subto  ArriveSite:  forall  <i,t>  in  SitesTimes  do 
A[i,t]  ==  sum  <j,i,m>  in  TransportArcs 

with  t  >  floor  (max(0 . 5/TrainsportArcsTrips  [j  ,  i  ,m]  ,  1)  )  : 

x  [ j , i ,m, t -floor (max (0 . 5/Transport ArcsTrips [j , i ,m] , 1) )] ; 


############################################################################# 
#  Link  travel  of  people  with  transporters 
############################################################################# 


subto  TransAccount2 : 

x [i , j ,m,t]  >= 


forall  <i,j,m,t>  in  TransportArcs*T  do 
z [i, j ,m,t]  ; 


subto  TransAccountl : 

w[i, j ,m,t]  >= 


forall  <i,j,m,t>  in  TransportArcs*T  do 
z [i , j ,m,t] ; 


subto  TransTripsW2:  forall  <i,j,m,t>  in  TransportArcs*T  do 

max(l , floor (Transport ArcsTrips [i , j ,m] )) *z [i , j ,m,t]  >=  w [i , j ,m, t] ; 

subto  TransTripsW3:  forall  <i,j>m,t>  in  TransportArcs*T  do 

x [i , j ,m,t]  <=  w [i , j ,m ,  t]  *TransportArcsMaxUse [i , j ,m] *TransCapacity [m] ; 


subto  TransTripsW4:  forall  <i,j>ni,t>  in  TransportArcs*T  do 
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x [i , j ,m,t]  >=  w [i , j ,m, t] *TransportArcsMinUse [i , j ,m] *TransCapacity [m] ; 

############################################################################# 

#  Accounting:  number  of  transporters  in  use  at  a  given  time 
############################################################################# 

subto  TransUsage:  forall  <i,j,m,t>  in  TransportArcs*T  do 

if  (TransportArcsTrips [i , j ,m]  <  1)  then  sum  <s>  in  {l..t}- 

with  s  >=  (t+l-ceil (1/TransportArcsTrips [i , j ,m] ) ) :  z[i,j,m,s]  ==  u[i,j,m,t] 
else 

z[i , j ,m,t]  ==  u[i, j ,m,t] 

end; 

############################################################################# 

#  Constraint  on  number  of  return  trips  for  assets  requiring  more 

#  than  one  time  period  of  travel 

############################################################################# 

subto  TransTrips:  forall  <i,j,m,t>  in  TransportArcs*T  do 

if  (TransportArcsTrips [i ,j ,m]  <  1)  then  sum  <s>  in  {t . . lastTime} 

with  s  <=  (t+ceil (1/TransportArcsTrips [i , j ,m] )-l) :  z[i,j,m,s]  <=  TransQty[m] 

end; 

############################################################################# 

#  Force  number  of  trips  for  a  transporter  on  a  particular  route/time 
############################################################################# 
subto  ForceTrips:  forall  <i,j,m,t>  in  TransportArcs*T  do 

if  (FixedTransportTimes [i, j ,m,t]  >=  0) 

then  w[i,j,m,t]  ==  FixedTransportTimes [i , j ,m,t] 

end; 

############################################################################# 

#  Constraint  on  number  of  transport  assets 
############################################################################# 


subto  TransQty: 

sum  <i , j ,m> 


forall  <m,t>  in  M*T  do 
in  TransportArcs :  u[i,j,m,t]  <=  TransQty[m]; 


############################################################################# 
#  Implements  blackout  periods  for  arrival  and  departure  at  sites 
############################################################################# 
subto  BlackOutA:  forall  <i,t>  in  Sites*B  do 

if  (t>0)  then  A[i,t]  ==  0 
end; 

subto  BlackQutD:  forall  <i,t>  in  Sites*B  do 

if  (t>0)  then  D[i,t]  ==  0 
end; 


############################################################################# 
#  Transport  departure  blackout  periods 

############################################################################# 
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subto  TransBlackout :  forall  <i,j,m,t>  in  TransportArcs*T  do 

if  ((t  mod  Time [3] )  <  TransStart [m]  or  (t  mod  Time [3])  >  TransEnd[m]) 
then  z[i,j,m,t]  ==  0 

end; 

############################################################################# 

#  Compute  an  approximation  of  the  average  time  in  system 
############################################################################# 
subto  AvgTimeCons:  AvgTime  == 

sum  <a,t>  in  SH*T  :  t*A [a,t] /totalPopulation 
-  sum  <b,s>  in  Sites*T  :  s*Arrival [b, s] /totalPopulation; 


DRDC-RDDC-2015-R074 


57 


List  of  acronyms 


1st  Cdn  Div  HQ  1st  Canadian  Division  Headquarters 


ADM(S&T) 

Assistant  Deputy  Minister  Science  and  Technology 

AFIT 

Air  Force  Institute  of  Technology 

AN 

Affected  Nation 

AP 

Assembly  Point 

CAA 

Center  for  Army  Analysis 

CAF 

Canadian  Armed  Forces 

CBSA 

Canada  Border  Services  Agency 

CECP 

Consular  Emergency  Contingency  Plan 

CEP 

Canadian  or  Eligible  Person 

CIC 

Citizenship  and  Immigration  Canada 

CJOC 

Canadian  Joint  Operational  Command 

COIC 

Commandement  des  operations  interarmees  du  Canada 

CONPLAN 

Contingency  Plan 

CORA 

Centre  for  Operational  Research  and  Analysis 

CPAT 

Contingency  Planning  Assistance  Team 

CSIS 

Canadian  Security  Intelligence  Service 

DES 

Discrete-Event  Simulation 

DFATD 

Department  of  Foreign  Affairs,  Trade  and  Development 

DND 

Department  of  National  Defence 

DRDC 

Defence  Research  &  Development  Canada 

EC 

Evacuation  Centre 

EM 

Eastern  Mediterranean 

FAC 

Forces  armees  canadiennes 

GUI 

Graphical  User  Interface 

km 

kilometers 
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MAECD 

Ministere  des  affaires  etrangeres,  du  commerce  et  du  developpement 

MEP 

Mission  Emergency  Plan 

M&S 

Modelling  and  Simulation 

NATO 

North  Atlantic  Treaty  Organization 

Nbr 

number 

NCG 

NEO  Coordination  Group 

NEO 

Non-Combatant  Evacuation  Operation 

OEN 

operation  d’evacuation  de  non-combattants 

OPLAN 

Operational  Plan 

OR&A 

Operational  Research  and  Analysis 

PA 

Population  Area 

PfP 

Partnership  for  Peace 

RCMP 

Royal  Canadian  Mounted  Police 

RS 

Repatriation  Site 

SAS 

Systems  Analysis  and  Studies 

SH 

Safe  Haven 

STO 

Science  and  Technology  Organization 

STONE 

Simulation  Tool  for  Optimizing  Non-Combatant  Evacuation 

STONE(Opt) 

STONE  optimization  component 
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